automake
[Top][All Lists]
Advanced

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

Re: Circular dependency


From: Guillaume Rousse
Subject: Re: Circular dependency
Date: Thu, 30 Nov 2006 10:24:19 +0100
User-agent: Thunderbird 1.5.0.8 (X11/20061110)

Stepan Kasal wrote:
Hello,

On Thu, Nov 30, 2006 at 09:31:19AM +0100, Guillaume Rousse wrote:
Stepan Kasal wrote:
You specified the dependency:

  corelib/camlimages.ml <-- Makefile

This is not correct.  You should specify the ultimate primary sources
instead of `Makefile'.  Prehaps `Makefile.am' is enough?

It was to catch configure runs, so I used config.status instead.

so it looks like this now:

Makefile <-- Makefile.in <-- .depend <-- corelib/camlimages.ml <--
<-- config.status

There is still a problem with this setup, you are breaking the rule
that "distributed files should not depend on non-distributed ones."

Let me explain:
Imagine you release a tarball of your package, and someone unpacks it
and runs the usual
        ./configure ; make
to build it.
config.status was created, so automake has to be run to refresh
Makefile.in.  This is not the expected behaviour: Makefile.in is
supposed to stay unmodified.
The inclusion of the .depend file is a temporary solution to make me able to at least compile the project locally. But I just figured the issue of egg-and-chicken problem between the source file generation, and the dependencies computation, thanks for insisting on it :) I could safely remove the generated files from the list of dependencies for dependencies computation, I think.

So, to get back at my original question, what's the proper way of expressing dependencies for a generated source file through configure-time substitution:
foo: foo.in config.status

or, as in autoconf documentation:
foo: foo.in Makefile

This cas cause real-world problems: when someome performs two VPATH
builds from the same source tree, the two rebuilds of Makefile.in
coming from the two builds present a race condition.

I'm afraid it can be easy to avoid this problem, though.
One solution is to enhance Automake so that it does dependency
tracking of ML programs.
That's what I'm intending to do. I'll have a look at automake code to understand how it is done.




reply via email to

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