[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul D. Smith
Subject: Re: problems with $(eval include...)
Date: Fri, 27 Jun 2003 16:40:41 -0400

%% Fabio Alemagna <address@hidden> writes:

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

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

I wasn't suggesting automake in total, I was suggesting their dependency
generation style only... this is basically what's described on my

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

  fa> exe: obj1.o obj2.o obj3.o

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

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

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

This is not reliable.

The instant you want to start allowing parallel builds, which are
critical for today's software builds and for taking full advantage of
today's hardware, your method is no longer guaranteed to work.

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

I thought you sent me an email saying that using the CVS source, it
worked?  That's how I read it; if it still doesn't work with the CVS
code please let me know and/or file a bug.

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

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

I agree the core dump needs to be solved (if it's not already in CVS).

However, I'm not so sure I agree that the method your using would be
supported.  I don't know that it wouldn't be, but I'm not at all
prepared to say right now that using $(eval ...) inside a command script
to enhance or modify make's internal dependency graph by adding more
prerequisites, would work.

Make carries a lot of internal state during its walk of the dependency
graph, like where it is, what it's looking for, etc., and if you go
modifying the structure of that graph while make is in the middle of
resolving it I can't say for sure that everything will work properly.

 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

reply via email to

[Prev in Thread] Current Thread [Next in Thread]