[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A quick idea about dependencies w.r.t. files depending on `nodist_..
From: |
Ralf Wildenhues |
Subject: |
Re: A quick idea about dependencies w.r.t. files depending on `nodist_...' files |
Date: |
Thu, 18 May 2006 07:12:45 +0200 |
User-agent: |
Mutt/1.5.11+cvs20060403 |
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