Re: Make includes (was Re: Time to update documenatiopn regarding supported make implementations?)

[Tom Tromey <tromey at redhat dot com>]

>>>>> "DJ" == DJ Delorie <dj at redhat dot com> writes:

DJ> Yes and no.  The root problem is "gnu make is required".  One facet of
DJ> this is the includes.  There are multiple ways of fixing the includes
DJ> part, one of which is to handle dependencies the same way everyone
DJ> else does.

Ok.

FWIW, I think the current (1.[67]) automake approach to dependency
tracking is ok.  It handles dependencies on the build machine, which
has some nice properties, for instance the dependencies properly
follow the configuration.

Now, this approach relies on `make' having include support, and we
check for this at configure time.  If there is no include support, we
just disable the dependency tracking.

I haven't heard of a make without some sort of include support.  We
know the code works with any make supporting `include' (including GNU
make) and also BSD makes.  Plus I'd argue that any gcc developer is
going to have such a make available anyway.

So I really see this as independent from the GNU make issue.  We could
easily use the automake dependency tracking mechanism without
requiring GNU make.  (Whether or not we want to is a different
question.  I think it would be fine, but I'm sure some people won't
like it for the usual sorts of reasons, e.g. requiring yet another
build-time script.  The overhead is pretty low, though, if you are
using 1.7.x and building with a recent gcc.)


Removing the GNU make dependencies from libjava is a different
problem.  Somehow changing libjava to use a different style of
dependency tracking is not the hardest part (and in fact if we moved
to automake 1.7, this part of libjava would no longer rely on GNU
make, as above).

The libjava GNU make dependencies can be characterized:

* Dependency tracking support.  As above.

* Use of `%' rules.  Most instances of this can be fixed by moving to
  a newer automake which more easily allows the .o files to be put in
  subdirs.  For the headers we'd probably need to think of something
  new.

* Use of $(shell ...).  These are used to work around command-line
  length limitations and need some new approach.  Perhaps putting the
  long file lists in a file that is included into Makefile.am would
  work; we could manipulate this file to generate the object list in
  the targets.


When you say that other parts of the tree have their own dependency
tracking code, do you mean things like the bfd directory?  That code
predates the current automake approach; when Ian converted bfd and
friends to automake, the automake dependency tracking at the time
really wasn't appropriate.  Things have changed since then.

Tom