[Gllug] Bison question

[Nix]

On Wed, 04 Dec 2002, Tethys moaned:
> Make is essentially very sound. All it really needs is updating to take
> account of the fact that Java broke the 1:1 mapping between source and
> object files that had existed since the dawn of time. D'oh!

It could also do with a better way to do automatic dependency
computation; as it is you have to roll your own, which is *hard*.

> Automake, however, is fundamentally flawed by design. It assumes you can
> infer certain thing by just looking at what you get when you #include
> certain header files.

Um, WTF? Automake makes no such assumptions; its job is makefile
generation, not portability.

This sounds more like Autoconf, only what you say has not been true of
Autoconf for ages either.

>                       Unfortunately, this will never be a reliable way
> to find out what a system supports. The *only* way to do that is to
> compile and link a program that makes use of those features. This is

This is not necessarily wise. Compiling, linking and running programs to
test feature presence is what Autoconf normally does, but such simply
doesn't work when cross-compiling; sometimes, you can't even
meaningfully link in that case. Autoconf prefers to determine results
using compilation alone; e.g. AC_CHECK_SIZEOF now works without any
link or run step.

(In general, run steps are a bad idea and should be avoided if at all
possible.)

If you look at any version of Autoconf-2.5x (which have been out for
more than a year now), you'll find that AC_CHECK_DECL / AC_CHECK_DECLS
do do a test compilation.

> actually just a case of being overfeatured. Remove AC_EGREP_HEADERS,

This is deprecated in the documentation, fairly strongly:

,----
|    Sometimes one might need to run the preprocessor on some source file.
| _Usually it is a bad idea_, as you typically need to _compile_ your
| project, not merely run the preprocessor on it;
`----

but certain projects *require* this, and wouldn't work without it; so
it can't practically be obsoleted and replaced with something else with
different semantics.

> and force the use of AC_TRY_COMPILE instead,

This macro is obsolete, and has been since Autoconf-2.50.

The _Upgrading from Version 2.13_ section of the Autoconf manual has an
entire node deveoted to AC_TRY_COMPILE, AC_EGREP_HEADERS and why you
shouldn't use them; you're complaining that something is a bad thing
when it's been deprecated, documented and replaced with better
alternatives for more than a year...

>                                               and automake becomes much
> more sane.  Actually, my biggest gripe with automake is that they've
> made the user interface for the generated configure script a thing of
> beauty. But they forgot to do the same for the user interface seen by
> the developer, which frankly sucks...

This is still Autoconf stuff, not Automake. You haven't said anything
about Automake yet. (Automake sucks, but not for any of the reasons
you've mentioned.)

And Autoconf-2.5x has a very nice warnings layer, a debugging/tracing
layer, and oodles of docs. It's still wierd as hell, but it's better
than all its competition.

-- 
`Ah, but don't you feel the jackboot of state oppression whenever you have
 to deal with the uniformed storm-troopers of government bureaucracy, viz.
 the bus company ticket inspectors?
 Damn you for a Stalinist stooge!' --- Charlie Stross

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug