Re: (no subject)

[Patrick Lögdahl]

Philip Guenther wrote:
> > I'm having a problem with automatic dependency generation from 
> > source-files
> > that depend on  auto-generated header files.
>
> The order-only prerequisites added to GNU Make in version 3.80 provide
> a fairly clean solution for this.  In order for the make to succeed
> before any dependency information have been generated, make will need
> to build the auto-generated files first.  So, add an order-only
> dependency of all the object files on the auto-generated files.
>
> > SRC := main.cpp A.cpp   # NOTE: A.cpp is auto-generated by the IDL tool
> > OBJS := $(SRC:.cpp=.o)
> > DEPS := $(SRC:.cpp=.d)
>
> $(OBJS): | A.cpp
great, this is probably exactly what i'm looking for. I see how that 
would fix the problem.
But my question is why not $(OBJS): | A.h ? (maybe a typo...)

In my actual system I added a variable AUTOGEN_FILES, that all modules 
adds their autogenerated files to, and the root Makefile has a 
order-only dependency

$(OBJS) : | $(AUTOGEN_FILES)

It works a charm, thanks a lot Philip!
> ...
> > * I could make some phony targets and make sure that all auto-generation
> > steps are performed  first. This doesn't help much though when the
> > auto-generated files are in another module. I  would have to litter the
> > makefiles with "high-level" dependecies between modules. I suspect  that
> > this will quickly deteriorate to a scheme that will be equivalent to
> > remaking all other  modules prior to making the current module.
>
> IMHO, the problem here is that the overall setup is broken.  If the
> modules are truly independent, then install the dependent module's
> 'output' files somewhere for use by the other modules instead of
> (re)building them as part of other modules.  If they *aren't*
> independent, then go read the "Recursive Make Considered Harmful"
> paper and stop pounding your head on the problems that recursive make
> creates.
Well, I actually already have a non-recursive setup. Of course the 
modules aren't *truly* independent ( in that case I
wouldn't have this problem no?). In the real world scenario its more 
like this:
proj
->Mod_1
...
->Mod_n
->Mod_n+1
...
->Mod_m

The set (Mod_1 .. Mod_n) can be considered a baseline (but not strictly 
so), and these modules are typically compiled and installed
(ie the developer does not have the source tree available)

(Mod_n+1 .. Mod_m) are add-ons (that *depend* on functionality in the 
baseline) that the developer is working on.
The thing is that over time, the set of modules that are "pre-compiled" 
will change, and will also vary from time to time
(ie a developer could be fixing bugs or working on add-ons that require 
new functionality in the baseline).

The developer could then just check out the source tree for Mod_X and 
(hopefully) just 'make' as usual