Re: [Tinycc-devel] autoconfiscation

[Rob Landley]

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.