automake
[Top][All Lists]
Advanced

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

Re: Circular dependency


From: Stepan Kasal
Subject: Re: Circular dependency
Date: Thu, 30 Nov 2006 10:53:12 +0100
User-agent: Mutt/1.4.2.1i

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.

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.
A kludge might be to emulate the dependency tracking by using
make-time includes.  If you are willing to do it portably, you need
the ugly lines with @am__quote@, mentiend by Ralf.  Or, if you are
willing to limit the users to GNU make, you could hide the include
directive like this:

MY_DEPENDENCIES = include make.deps
$(MY_DEPENDENCIES)

HTH,
        Stepan




reply via email to

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