On Wed, 2005-10-12 at 19:28 +0200, [EMAIL PROTECTED] 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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
