[Top][All Lists]

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


From: Ralf Wildenhues
Subject: Re: $(DEPDIR)
Date: Tue, 29 Jun 2010 07:02:17 +0200
User-agent: Mutt/1.5.20 (2010-04-22)

* Bruce Korb wrote on Sun, Jun 27, 2010 at 12:56:02AM CEST:
> On Sat, Jun 26, 2010 at 12:19 PM, Ralf Wildenhues wrote:
> > * Bruce Korb wrote on Sat, Jun 26, 2010 at 06:30:29PM CEST:
> >> I've fiddled my playtime tool "autogen" to emit dependency info:
> >> > stamp-opts : $(AUTOGEN_opts_SList)
> >> >
> >> > $(AUTOGEN_opts_TList) : stamp-opts

FWIW, if you want to be portable also to non-GNU makes, and the rest of
your post indicates you might be, then you shouldn't use := for variable
assignment.  Esp. since it makes little sense for your one-time
variables in the dep file.

BTW, is the stamp aka dependency file generated atomically, and only if
compilation succeeded?  If not, you have a problem with interrupted
builds, or we need a rule that writes then renames the file.

> There are problems with getting make file dependencies correct when
> multiple inputs yield multiple output files.  I have resolved this by creating
> an output file that will always be older than any other output file.  Thus,
> it can be the sentinel file that attests to the build rule having been 
> applied.

Good thinking.

> Conveniently enough, this sentinel file also contains make file syntax
> dependency information.  So, with the addition of:
>     include dependency-file-name
> make would then know when source files become out of date with
> respect to this sentinel file ("dependency-file-name").  However,
> looking at the include line:
>    @AMDEP_TRUE@@am__include@ @address@hidden/$(DEPDIR)/address@hidden@
> I am guessing that when make supports include and what the include
> syntax might be varies from platform to platform.


> Further, buried down
> in the generated configure somewhere is some code that will create
> an essentially empty (dummy) dependency file so that the make include
> directive will not fail.


> >  Do you
> > intend to write a patch for Automake, or is this something purely
> > external for one specific project, or to be more generally usable for
> > all users of Autogen inside a project using Automake for building?
> That would be the hope.

I shouldn't ask questions containing "or".

>  I'd like to augment automake with a standalone
> capability to say, "'dependency-file-name' is a build target and it contains
> make dependency information for makes that can cope with reading it."
> Perhaps along the lines of:
>     mymodule_DEPEND_TARGET := dependency-file-name
> and a dummy dependency-file-name gets created along with all that
> sedding magic to convert that "@am__include@" line into a make inclusion.

That sounds like a good idea to me, but I haven't had time to think
through the details yet.  One definite problem is namespace issues:
stamp-opts is too general for use in Automake; what about at least a
tool prefix, as in ag-stamp-opts, instead, for the file name as well
as the rule of course?  Better even a couple of knobs to twist.

Another is the mymodule_DEPEND_TARGET variable name, I don't like that
yet either.

As long as the feature isn't available in Automake, your users can work
around by adding
  @AMDEP_TRUE@@am__include@ @address@hidden/$(DEPDIR)/address@hidden@

to their files; this does require the `no-dependencies'
Automake option to not be used, and it requires one of the compiler
macros AC_PROG_{CC,CXX,F77,...} to be used.

Actually, the idea as it stands does not degrade gracefully when the
author uses the no-dependencies option; in that case, automatic
dependencies should not be used, but if we drop your file, I think the
build will fail, no?


reply via email to

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