Re: (Off-Topic) Autoconf

[Jonathan S. Shapiro]

On Wed, 2005-10-12 at 19:28 +0200, address@hidden wrote:
>    Setting aside the use of M4, which is another abomination,
> 
> M4 is quite a good choice for this.

In my opinion, M4 is functionally acceptable for the task, and the task
probably does call for a macro processor. My objection is that M4 is a
particularly ugly and obscure macro processor with perverse whitespace
handling.

> 
>    the fundamental design flaw in autoconf is that it tests
>    compatibility by executing programs on the target platform rather
>    than consulting a database.
> 
> I don't know of any test that does this that is distributed with
> autoconf.  Maybe you mean tests that people have writtten, then this
> is true, but then it isn't a flaw in the test not in autoconf.  Also,
> you can make autoconf use a database, it is called a config.cache
> file, and I often use it for bash 2.x which had a broken set of tests
> (3.x fixed this, instead it just defaults to some semi-sane value and
> spits out a warning).

Have you look at any of the "macro is defined" checks recently? They are
performed by building a small test file and attempting to compile it on
the target platform.

Yes, config.cache is (sort of) a database. Of course, if I were able to
run configure successfully enough to get a config.cache, I probably
wouldn't need to modify config.cache, now would I?

>    how exactly do you test the integer size on a cross target?
> 
> By not depending on the integer size.

Please explain how to do that in a C program?

>    Have you tried building a cross compiler lately with GCC?
> 
> I have, quite easy, far easier than it was a few years ago.

It's getting better, but it's not there yet. Some of the ways in which
it is getting better are highly linux-centric. The GCC cross build is
*much* less friendly for non-UNIX targets than it used to be.

>    Finally, the design of autoconf does not promote portability.
> 
> It does promote portability.  But people are often ignorant as to
> writting good configure.ac scripts, which is a pita if you try to
> write your own specific tests.

Nonsense. What it promotes in practice is programs that make
platform-sensitive decisions about which headers to use and which macros
to rely on. I agree that a robust way to detect these dependencies is
desirable, but the right answer for this sort of thing was a portability
toolkit layer. The apache portability library comes to mind as an
example of how this should have been done.

shap