GNU bug report logs - #10930
touching dependency files, take 2

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10930 in the body.
You can then email your comments to 10930 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bruce Korb <bkorb <at> gnu.org>
To: bug-autoconf <at> gnu.org, bug-automake <at> gnu.org, bug-make <at> gnu.org
Subject: touching dependency files, take 2
Date: Fri, 02 Mar 2012 09:08:35 -0800

This is a autoconf, automake and make question, rebuffed in gnulib.
It's partly autoconf because autoconf stages dummy dependency files
so the make include function won't choke.  It is partly make because
I find it a bit tricky getting the dependencies just right.  It is,
I think, mostly an automake question since I think that the
machinery behind the AMDEP/DEPDIR configury stuff is automake.

The issue is that I have this tool that takes multiple input files
and produces multiple output files.  "make", of course, was conceived
with the idea that each production rule produces one output file.
The workaround is to figure out how to have one target file represent
the production of the many, often done with "stamp" files.  e.g.

> target : $(deplist)
>     touch $@-temp ; $(do-stuff) ; mv $@-temp $@
>
> $(target_list) : target

This is all well and good when dealing with yacc or lex where the
number of inputs and outputs is fairly well constrained.  My tool
is not so well constrained.  So I took a page from GCC.  I use
"-M" to tell it to produce make file friendly dependency files.
But I took it a step farther, and that's what leads to this
what-is-the-best-approach question.  (I'm getting there.)

The make fragment produced contains a list of sources, a list of
targets, a sentinel target and the dependency file itself.
The sentinel and the dependency fragment may be the same file.
Here's an abbreviated example:

> t = output ...
> s = input ...
>
> .deps/output-done : $(s)
> $(t) : .deps/output-done
>         @:

the main makefile is responsible for the actual "output-done" rule.
It would be nice to not have to have that basically empty production
rule, but I haven't found a way to avoid it.  Without it, you get
"no rule to make output" errors.

Question 1:  Is there a way around this empty rule?

When "-MP" is added to the command line, I now produce some phony rules:

> .PHONY : clean-.deps/output-done
>
> clean-.deps/output-done :
>         rm -f  $(t)
>         touch -t 199912312359 .deps/output-done

I'm not happy with that.  This is an example where the sentinel file is
the dependency file.  Were they different, then it would be:

> t = output ...
> s = input ...
>
> stamp-foo : $(s)
> $(t) : stamp-foo
>         @:
>
> .PHONY : clean-stamp-foo
>
> clean-stamp-foo :
>         rm -f stamp-foo $(t)

I'm also unhappy with this because I now have this stamp file wart,
but I also don't have the "touch -t 199912312359" wart.

Question 2:  Is there a better way?

I'd also like to add a line to that fragment:

> ag_clean_targets += clean-stamp-foo

but it isn't portable.  So, pending the decade wait for the "+="
make operator, there must be ways to test for make program capabilities.

Question 3:  I'm sure it's obvious and I'm just oblivious, but how do
I tell if the current make supports "+=" at configure time?

Of course, it isn't clear that my clients could use it anyway since
they'd have to construct the list for non-"+=" supporting platforms.
This renders the utility of $(ag_clean_targets) to be rather small.

Any suggestions?  Thank you!!  Regards, Bruce

Message #8 received at 10930 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Bruce Korb <bkorb <at> gnu.org>
Cc: 10930 <at> debbugs.gnu.org
Subject: Re: bug#10930: touching dependency files, take 2
Date: Fri, 02 Mar 2012 21:23:33 +0100

tags 10930 notabug
close 10930
thanks

Hi Bruce.  By writing to bug-automake, you have automatically opened
a new report in the Automake bug tracker; still, in your mail, you only
ask a question, and don't report any actual bug AFAICS.  To avoid extra
noise in the tracker, I'm thus closing the report you've (probably
unwittingly) opened; you should still be able to continue the discussion
normally though.  In case you think the issue you are facing is truly
due to an automake bug, feel free to re-open the report.

Regards,
  Stefano

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.