* Segher Boessenkool segher@chello.nl [020607 13:23]:
Except we rely on compiler defines and prerequisites to get towards a defined build set (which probably sucks). If we have to use this functionality anyways, it might be interesting to look at autoconf. But then again we won't get rid of all perl stuff, so using autoconf just adds another player to the game.
Please let's not use autotools :)
Besides their implementation is a bit far from the goal (portability), autoconf and friends cause lots of trouble, not only with new platforms but also with newer versions of autoconf etc. We definitely don't want that.
Just a dumb idea, could we rewrite the preprocessing and testing completely in C? I know that there are a lot of issues with perl on
Nope, cpp can't do all that's necessary. Btw, once we have a working Forth compiler, we can use that to bootstrap itself :)
You're talking about forth -> binary translation? That is not what we want, I guess. Can you explain?
newer platforms, which could make it hard to get paflof running on new machines, even if we already have a gcc. Ugly though. If this is
Cross-compilers save the day :)
Cross compilers is exactly where this stops working. If I cross compile for SH1 CPUs using a crosscompiler on Intel x86, my perl nor my gcc will never tell me whether my 'long' is 32 or 64bit on the target platform. We probably can't even use this to check for TI mode availability
I hope to finish the "Forth command group" today :)
How much work has to be done here? How far are we from being able to read FCode with this (i.e. use the work in the fcode/base/ directory already done? Please make sure we don't do duplicate work here. " text" is the only one missing to get the mandelbrot signature, one of my toke test programs, running. Then we can start using the example code and really testing the Fcode layer on top.
Stefan