bug-gnu-utils
[Top][All Lists]
Advanced

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

Issues using .SECONDARY and .PRECIOUS to prevent deletion of intermedia


From: Brian Vandenberg
Subject: Issues using .SECONDARY and .PRECIOUS to prevent deletion of intermediate files
Date: Wed, 28 Mar 2012 18:24:12 -0000
User-agent: G2/1.0

The documentation for .secondary gives the impression you can
use .SECONDARY with no targets to prevent make from deleting
intermediate files, but this approach has side-effects that can
prevent things from building.

As an example: I have a fairly large build with a large number of
headers used that are generated from Fortran code.  The tool used to
generate the Fortran code is built within the same code-base.  I added
targets of the form:

%.h : %.inc ${THE_TOOL}
  ${THE_TOOL} ${<}

The headers actually get symlinked to a separate location within the
build -- please, I don't need comments on this architecture, I'm
already pushing to eliminate that from the build.  So, the symlinks
themselves are the targets being built, whereas the header is an
intermediate target.

${THE_TOOL} gets treated as an intermediate target when I
use .SECONDARY without any dependencies specified, which seems to have
some odd side effects.  If I specify a given symlink as a primary
target, it induces the tool to build without problem, then the rule to
generate the header to be symlinked is kicked off -- everything is
fine.

However, when I run the full build, it delays building the tool quite
a bit, but the fact it isn't built yet doesn't prevent the recipe that
uses the tool from executing.  I've traced it through the debug output
with '-d', and there isn't enough info for me to draw a conclusion
other than what I've outlined already.

Instead of using .SECONDARY, I tried using .PRECIOUS with:

.PRECIOUS: %.cc

... where some .cc files are generated dynamically.  However, the
target building them is specified as:

/some/fully/qualified/path/something%.cc: whatever.cc

.PRECIOUS only matches if the target name matches -- it isn't using
the % to do pattern matching.

This differs in behavior from other areas where patterns are allowed.
As an example:

%_blah.o : SOME_VARIABLE = whatever

... will work, in spite of the fact the target that actually builds it
is given as:

%.o : %.cc

Comments?  Questions?  Suggestions?



reply via email to

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