Re: depcomp deficiency [was: m4-1.4.7 build feedback]

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Nelson H. F. Beebe on 9/27/2006 7:23 AM:
> Thanks for the comments on the automake testing in the depcomp
> code.
> 
> 
> Here is what POSIX (IEEE Std 1003.1-2001: Revision of IEEE Std
> 1003.1-1996 and IEEE Std 1003.2-1992) has to say:
...
> As far as I can see, POSIX-2001's requirements for compiler options
> are met by the BSD c89 and c99.  In particular, there are no
> provisions for generation of dependencies, like gcc's -M option family
> offers.

Yes, we are aware that -M is not standardized.  That is why depcomp knows
several flavors of how to generate dependency tracking, including a method
that involves no compiler support (by looking at preprocessor output in a
separate process instead).  By default, automake projects turn on
dependency tracking for compilers that can do something like -M, where the
dependency tracking is a side-effect of compilation with minimal overhead,
and leaves it off for compilers that require a separate process.  The
problem that you reported is that you have a compiler that fooled
automake's depcomp into thinking it supported side-effect dependency when
it really didn't.

> 
> I've never understood why some packages feel the need to generate
> dependencies at build time at every end-user site, rather than at a
> single developer site.  In my own packages, I maintain the Makefile
> dependencies myself, and don't require their generation during builds.

Then you should use './configure --disable-dependency-tracking' - this is
exactly what it was invented for.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFGn7Z84KuGfSFAYARAqzaAJ9b5cSpx5s0R4Ygida/llAlKPPJfgCeIjFq
SOcgSHb1dmp6XoBzhZ8yR0g=
=izMx
-----END PGP SIGNATURE-----