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

[Paul D. Smith]

%% Fabio Alemagna <address@hidden> writes:

  fa> This is unacceptable for VERY large projects with lots of modules
  fa> and .c files belonging to those modules: say I want to build
  fa> module A and B only, which don't depend on any other module; since
  fa> I include ALL .d files for ALL modules and ALL .c files anyway, it
  fa> doesn't matter how many modules I want to build, ALL .c files from
  fa> ALL modules will be checked anyway, which is wasteful.

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

  fa> The other solution would be to have make let you define other ways
  fa> than timestamps checks to see whether a target needs to be rebuilt
  fa> or not: if for example I could write prerequisites which expanded
  fa> macros only when the target were invoked, then I could write
  fa> macros which expanded to an empty target if the file needed to be
  fa> built for some reasons - thus leading the target to be rebuilt -
  fa> and to nothing if the target doesn't need to be rebuilt. This
  fa> would be a very useful feature, imho. It, I think, would just
  fa> require to define a new syntax for this special macro, like for
  fa> example $@(macro): $@ would not be usable in a prerequisite list
  fa> anyway, so using it like that is perfectly possible, I think.

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.

Nevertheless, it has been requested before that customizable
"up-to-date?" queries be allowed.  If such a thing were to happen it
would definitely not happen until after the integration of a scripting
language with GNU make (Guile; this is on the TODO list as well) and it
would be done using that; you could "override" the default "up-to-date?"
query by supplying some kind of Guile script or something.

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