[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: $(DEPDIR)
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 Makefile.in 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.
Yep.
> 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.
Yep.
> > 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 Makefile.am 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?
Thanks,
Ralf