Re: problems with $(eval include...)

[Fabio Alemagna]

On Fri, 27 Jun 2003, Paul D. Smith wrote:
> As pointed out before, if you do the dependency generation the way
> automake does it (as described on my web site) you won't have any of
> these problems.

automake uses recursive makefiles, which is something I want to avoid.

>   fa> My solution (if only it worked) is to include the .d files for a
>   fa> given module ONLY when that module is about to be built, which is
>   fa> right after the module's rule is run, and right before the .o
>   fa> rules are run.
>
> Eh?  I don't think this will work, or else I'm misunderstanding what
> you're saying.  In make, a target's prerequisites are always built
> _BEFORE_ that command script is invoked.  So, the $(eval ...) in the
> module script will not be invoked until after all the .o rules are run
> (if the module depends on the .o's).

Perhaps I've not explained myself very well.

First of all, say I want to build the executable "exe", which depends on
obj1.o, obj2.o and obj3.o:

exe: obj1.o obj2.o obj3.o

Now, I'd want to include the dependency files for the various obj?.o,
however I want to include them only when exe is about to be built. This is
what I can do (sometimes works, sometimes doesn't):

exe: exe-deps obj1.o obj2.o obj3.o

exe-deps:
        $(eval -include obj1.d obj2.d obj3.d)

The reasoning behind that is the following: when exe is to be built, make
checks all of its prerequisites. The first prerequisite it encounters is
exe-deps, which make re-does, but the command list for exe-deps makes make
include some files which, incidentally, define some other rules which have
as targets the various obj?.o. When make is done with including these
files, then it goes back to check the rest of the prerequisites of exe,
and finds that it has to check whether the various obj?.o needs to be
rebuilt, and thus it goes trough all the list of rules which have obj?.o
as target, _including_ the rules which have been included right before.

This, as said, works, but it has bugs which don't allow it to be really
usable.

> I think you need to step back and look at the problem space again.
> Working with an alternative method for dependency generation is, to me,
> a much simpler and more understandable way to go than something like the
> above.

I'm going away from that way of doing dependencies, I certainly don't want
to go back to it. Anyway, I'm pointing out a bug which needs to be solved
anyway.

Fabio Alemagna