This implementation appears to suffer from the various problems that
my proposed implementation fixes:
1. What does m4 put on the left-hand-side of the generated make
dependency rule when m4 is sending its output to stdout? There
is no general way for m4 to know what the target is in this
case. (Consider, e.g., when stdout is the write end of a pipe.)
My submitted patch avoids this problem by having the user
specify the generated rule's target explicitly on the command
line (always).
2. By creating both the dependency file and the actual m4 target
file in one step, you wind up being in danger of "circular
dependencies" -- running make twice in a row causes stuff to
be remade the second time. In certain cases, even an endless
succession of "make" invocations causes stuff to get remade
every time. Single commands that update two or more targets
at once are the usual cause of this behavior. The fix is to
have two separate rules in your Makefile:
a. One to create the dependency file (it runs m4 in
"dependency" mode and creates only the dependency file),
and
b. A second rule that invokes m4 in the "normal" way to create
only the "normal" m4 target.
This is how you avoid such circular dependencies. Single
Makefile rules that update multiple targets are generally a
recipe for circular dependencies and should be avoided
whenever possible. My proposed implementation avoids this
difficulty by replacing m4's regular output with the generated
dependency file -- m4 only generates one or the other, but
never both. Yes, your Makefile winds up having to run m4
twice (unless the dependency file already exists and is
up-to-date) -- but this is a small price to pay for having a
consistent build process.
David Warme
On Mon, 2010-10-25 at 11:39 -0600, Eric Blake wrote:
> On 10/19/2010 06:52 AM, Lorenzo Di Gregorio wrote:
> > Hello,
> >
> > I'm following up on this (
> > http://lists.gnu.org/archive/html/m4-discuss/2010-10/msg00003.html) post,
> > because I've managed to find some time and write a patch for supporting
> > dependency generation with M4, which is something I've been really missing
> > for my makefiles. You find the patch enclosed here as attachment.
>
> Thanks for taking the time to do this. I'm sorry that my m4 maintenance
> time has been less than stellar, lately.
>
> This is big enough that we would need copyright assignment on file
> before it can be incorporated. If this is something you are still
> willing to pursue, I can send you details off-list about getting FSF
> assignment in place.
>
_______________________________________________
M4-patches mailing list
M4-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/m4-patches
