%% Fabio Alemagna <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 _______________________________________________ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make