%% Raymond Nijssen <[EMAIL PROTECTED]> writes:
rn> ::: "PDS" == Paul D Smith <[EMAIL PROTECTED]> writes:
>> %% Raymond Nijssen <[EMAIL PROTECTED]> writes:
rn> As a result, my .a files are not deleted if a .o file fails to
rn> compile, and then my executable will link happily in a recursive
rn> make environment. This is undesired.
>> That means your recursive make environment isn't set up correctly.
rn> I don't get it.
rn> The submake does not delete the .a file, even though one of its .o
rn> dependencies fails. The .o file is deleted,
All true, but the submake will exit with an error code, since one of the
targets it tried to create didn't build correctly.
That means that that target in the parent make will fail (if it's
written correctly), and if you've got the prerequisites set up correctly
in the parent make, then once the submake fails to build no other
targets that depend on that submake working correctly should be
attempted, just like no link will be attempted when a .o fails to build.
To make, there's no difference between a submake and a compile of a .o;
if you have the proper prerequisites in place then once a target fails
you'll never build with "incorrect" files.
>> You should have prerequisites set up so that failures in a directory
>> ensure that no other directories that depend on the products of the
>> failing directory would be built.
rn> At this point there has not yet been a recursive invokation of make.
I don't understand what you're saying. Above you refer to "the submake
does not delete the .a file", etc... if there's no recursive invocation,
how can you have a "submake"?
rn> Actually it looks like .DELETE_ON_ERROR is working at all:
I assume you mean "isn't" here?
rn> CC=g++
rn> .DELETE_ON_ERROR:
rn> all:: libfoo.a
rn> libfoo.a: foo.o
rn> foo.o: foo.cxx
rn> $(CC) -c $<
rn> bogus:
rn> touch libfoo.a foo.o
rn> echo "asdf" > foo.cxx
rn> Shouldn't at least foo.o have been deleted?
Not according to the manual. The doc says:
Usually when a command fails, if it has changed the target file at
all, [...]
So generally the right thing to do is to
delete the target file if the command fails after beginning to change
the file. `make' will do this if `.DELETE_ON_ERROR' appears as a
target.
In your example, g++ (being a well-behaved compiler!) doesn't even try
to write the .o since there are compile errors. So, the target file
foo.o doesn't change, so make won't delete the file, even if
.DELETE_ON_ERROR is given.
You can do a proper test like this:
$ cat Makefile
.DELETE_ON_ERROR:
foo.x: foo.y ; touch $@; exit 1
bogus: ; touch foo.x ; sleep 1; touch foo.y
$ make bogus
touch foo.x ; sleep 1; touch foo.y
$ make
touch foo.x; exit 1
make: *** [foo.x] Error 1
make: *** Deleting file `foo.x'
The touch of foo.x causes make to think the target was changed, then
.DELETE_ON_ERROR causes make to delete it.
>> I cannot think of any way to get the behavior you're looking for
>> (if a target fails to build, then make deletes that target, plus
>> the target it was a prerequisite of, plus whatever _that_ was a
>> prerequisite of, etc.)
rn> If so, wouldn't that be a cool feature? It could simply work its
rn> way up following all the parents and delete the targets instead of
rn> bailing out.
Cool, or annoying, depending on your point of view :). Some people may
well be irked by this. Consider if you had 200 .o's in your library,
and recompiling the last one failed, so make deleted the library--now
the next time you run make not only do you have to build that .o but you
have to re-archive every .o because the library was deleted! If it
hadn't been deleted, you could just have rebuilt the failed .o, then
used "ar r" to replace that one .o instead of recreating the entire
library from scratch.
--
-------------------------------------------------------------------------------
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gnu.org http://www.paulandlesley.org/gmake/
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
