Subject: Re: documentation for in-tree autoconf & wrapper
To: None <current-users@netbsd.org>
From: Christos Zoulas <christos@astron.com>
List: current-users
Date: 01/08/2007 19:34:01
In article <6e9741c60701081106v47b8e22dpd91de03903ce6906@mail.gmail.com>,
Blair Sadewitz <blair.sadewitz@gmail.com> wrote:
>No, we cannot simply use autoconf this way.  The big win one gets with
>all the effort to use the reachover framework is elegant
>cross-building.
>The GNU autotools, in virtue of their design, implicitly assume that
>the host and target are the same.  Despite the fact that you can tell
>it "use my cross-tools", it will do as all too many politicians do and
>act as if it is doing what you want but cannot.  How can the
>autotools--which _execute_ small test programs to make critical
>decisions--produce useful binaries for the target platform by running
>tests on the build host?  It simply cannot.
>
>Granted, the situation is not as bad as it could be, for it's not like
>malloc() returns 0 on some NetBSD platforms and doesn't on others; and
>the modular Xorg developers have created some patches to make
>cross-compiling feasible.  However, I cannot comprehend how the
>autotools could possibly ensure code correctness unless they're told
>exactly what to do in myriad cases.  Then, if my reasoning is
>correct--and it very well could [embarassingly] be totally off--we'd
>have to cook up many lines of myriad configure flags for each platform
>(assuming there _ARE_ even flags for everything we need, which there
>may not be).  I suppose it comes down to the question of whether it
>would take longer to write actual makefiles using bsd.x11.mk or deal
>with the autotools in the aforementioned manner.
>
>Am I wholly off-base here?

In general we run configure to produce a config.h file for a particular
platform, and then hand-tune it to work on all the rest of the platforms.
Look at amd's config.h for example (the __NetBSD__ part). 

christos