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

[Ralf Wildenhues]

Hello Nelson,

* Nelson H. F. Beebe wrote on Wed, Sep 27, 2006 at 03:23:45PM CEST:
> 
> The BSD folks are a different religion from the GNU folks, so
> conflicts in software interfaces are to be expected.

Not really.  The Automake dependency tracking code tries quite hard to
work with any compiler (or compiler wrapper) thrown at it.  And
certainly there is a bug in it currently, and we're going to fix it.

> 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.

Which is just fine.  And the dependency tracking code works fine with
compilers that have no way of generating dependencies.  The issue is
much more special in this case: the FreeBSD compiler wrapper c89
accepts the options
  -MP -MD -MF -MT

if they appear _after_ all the other command line arguments, esp. the
source files; and in that case, it even produces correct dependency
output.  (Well, this to be expected: under the hood, there's a GCC doing
its work.)

c89 only fails to accept the command line if the above options appear
_before_ the source file.

The bug in Automake is that, for testing at configure time, a different
order is used as at compile time.  (I am going to propose a patch, but
I need to check some consistency cases first, so that this does not
happen again.)

And, to repeat, while I don't think it may strictly be called a bug in
the FreeBSD /usr/bin/c89 program to accept undocumented command line
arguments in some places but not in others (as both are undefined
behavior wrt. to what the standard has to say), it is certainly a
quality of implementation issue that c89 behaves this way, instead
of failing with both orderings.

> 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.

Well, first, it is very simple for the end-user to turn this mechanism
off:
  ./configure --disable-dependency-tracking

Then, it is only turned on by default if the dependency tracking
mechanism is "fast" in the sense that it can be done as a side-effect of
compilation.  To also turn on slow tracking mechanisms, you explicitly
have to write
  ./configure --enable-dependency-tracking

As a final comment, let me state that allowing to generate dependencies
at the end-user site is just a logic consequence of the general theme
that "every user is a potential developer": that's why autotooled
packages ship with configure.in/configure.ac, and aclocal.m4, and
possibly more files that would not be strictly necessary for an
end-user, but that serve as input files to generated files shipped with
the package.

Hope this helps a bit, and thanks again.

Cheers,
Ralf