[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
finer granularity in omitting errors from include statements sensible?
From: |
Michele Zamparelli |
Subject: |
finer granularity in omitting errors from include statements sensible? |
Date: |
Thu, 22 Mar 2012 09:18:35 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 |
Hi,
I have been trying to avoid these errors:
acsMakefileCore.mk:418: ../object/aaa.d: No such file or directory
== Dependencies: C++ ../object/aaa.d
using the dash in front of the include statement, just to find out that
it is apparently too large a hammer.
There is a customary rule for the automatic creation of dependencies files:
../object/aaa.o ../object/aaa.d : Makefile aaa.C ../include/toto.h
but if for whatever reason the commands for that rule fail (e.g. a
syntax error), the user merely gets a non zero return code but will
never know the reason for it.
I have also tried using the advanced auto dependency generation
technique explained by Paul D. Smith at
http://mad-scientist.net/make/autodep.html but concluded that avoiding
the first-run inclusion of freshly generated dependency files would deal
a deadly blow to using code generation solutions, in which one of the
prerequisites (say, ../include/toto.h) is missing from the file system,
but a rule exists to generate it.
Needless to say, we would like to continue to use code generation,
without having to hard code a sequentiality in the main target (e.g.
all: generate do_the_rest, not good for parallel builds), but also
avoiding the many (benign) error messages above.
I am wondering whether it would make sense to request that the dash in
front of the include statement merely silences off the "No such file or
directory" case, but not all other errors which may result from the
execution of the corresponding target.
Am I the only one in this situation? Is there an alternative?
Thanks in advance,
Michele
- finer granularity in omitting errors from include statements sensible?,
Michele Zamparelli <=