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.
