Hi Thomas, * Thomas Schwinge wrote on Thu, May 18, 2006 at 01:42:39AM CEST: > > The following idea might already have been discussed. I did not do > extensive research. If it was, please tell me and point me to it.
Well, I think every now and then someone comes and suggests foo_o_DEPENDENCIES. > Corrently code like the following... > > foo.c > #v+ > [...] > #include "bar.h" > > [...] > #v- > > ...--where `bar.h' is a `nodist_...' file, i.e. is generated by the build > system and is not shipped among the source files--is a bit problematic > when using Automake. If not explicitly told, Automake doesn't (can't) > know that `foo.c' depends on `bar.h' prior to trying to compile `foo.c', > while will--of course--fail if `bar.h' hasn't been built before, be it by > chance or by an stating an explicit dependecy of `foo.c' on `bar.h'. Solved by using BUILT_SOURCES. Yes, I know BUILT_SOURCES isn't the greatest solution, but works well enough for many uses. > When creating the files that'll be overwritten afterwards to hold the > source files's actual dependencies, `config.status' currently only puts > ``# dummy'' into e.g. `.deps/foo.Po'. > What if `config.status' didn't put ``# dummy'' into these files, but > ``$(DIST_SOURCES): $(filter-out $(DIST_SOURCES),$(SOURCES)'' instead? > Shouldn't that solve the above problem? filter-out is GNU make-specific. Cheers, Ralf
