On Monday 27 August 2007 8:01:50 am Peter Lund wrote: > On Mon, 2007-08-27 at 00:21 -0500, Rob Landley wrote: > > I'm all for improving the config and the makefiles (they need it), but I > > don't personally consider autoconf or automake to be an improvement. > > Thank you! > > That makes me feel safer about the project. > > I tried as an experiment last year to see how far I could get without > using any kind of configure script, just with a GNU makefile (*). It > turns out that one get everything auto* gives you plus it is faster, > more user friendly, more programmer friendly and doesn't result in > (extremely!) big configure shell scripts. > > > *) It has cached feature tests and header dependency tests.
If we're doing enough feature tests we need to cache the results, something is wrong. How about not having that many tests? Our ./configure step doesn't take 15 minutes to run (unlike some of the gnu projects), and I'd rather have the build take an extra 3 seconds than have the complexity of a configuration cacheing layer. From my point of view, the main issue is that users expect "./configure; make; make install". It's a user interface thing. In this space, "make menuconfig" is also fairly widely used (linux, uClibc, busybox), but tcc hasn't got nearly enough configuration options for something like menuconfig to make sense, and I'd rather not go there if we can avoid it. Our ./configure needs to support "--help". All I ever really use out of it is --enable-cross and --cc, although I can see specifying the prefix and various paths. (I have no idea what this "architecture dependent files" nonsense is since it doesn't install any architecture _independent_ files that I'm aware of...) But is our ./configure really probing the host system? (Looks.) Oh that's evil. Look, we don't CARE what machine we're building on. We don't. We care what the _target_ architecture is (NOT THE HOST), and that means we look at the pre#defined symbols the host compiler gives us. Do this: gcc -dM -E - < /dev/null Now look through the symbols and write the appropriate #ifdef tests. On Linux you'll have __linux__ and you can tell your architecture from these symbols: Arm: __arm__ Blackfin: __bfin__ m68k: __m68k__ ppc: __powerpc__ sparc: __sparc__ mips: __mips__ x86: __i386__ (yes even i686 gives you this symbol) x86-64: __x86_64__ And so on. Look at the output, grab the appropriate symbol. This tells you the machine your compiler will run on. And this is NOT necessarily the same as the machine your compiler will produce OUTPUT for... If you want to know if the machine you're on is 64 bit, look for __LP64__. The dance to find endianness seems to be: #ifndef __APPLE__ #include <byteswap.h> #include <endian.h> #if __BYTE_ORDER == __BIG_ENDIAN #define IS_BIG_ENDIAN 1 #else #define IS_BIG_ENDIAN 0 #endif #else #ifdef __BIG_ENDIAN__ #define IS_BIG_ENDIAN 1 #else #define IS_BIG_ENDIAN 0 #endif And that's only if you care about macos x. (Another platform I haven't got a test system for. They get mad if you try to run it under qemu, so I simply don't develop for it. They made the rules, not me...) > There are > commands (make targets) to list the caches and to flush them etc. > I /could/ make it generate a "config.h" file but it is cleaner to rely > on standards for the most part and a few -Dxxx=yyy parameters to the > compiler for the rest. The question that interests me is how much can ./configure _avoid_ doing? The current one is doing _way_ too much work. It's identifying a half-dozen platforms we don't currently support, and I actually think the _easy_ way to handle this is to generate all cross compilers by default and then have a small shell script create a symlink to the one that produces output for our host platform (if any). Note that right now, the code doesn't work right if you build it with -funsigned-char (which is why I added the flag to specify). Personally I prefer -funsigned-char because it makes your ascii handling naturally 8-bit clean, which makes things like utf8 handling easier. Not a _huge_ deal in a compiler, but still... :) I haven't tried building it in an x86-64 environment. I should do so... Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
