On Tue, Oct 26, 2010 at 3:41 PM, David M. Warme
<address@hidden> wrote:
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).
Well, now I'm a bit lost. Is this a question about the implementation or the description of a problem affecting the implementation?
The dependency on stdout is already contained in the makefile:
target : prereq1 prereq2 ...
m4 $^ > $@
what the -X,--depend option does is to generate a dependency file for all entries in $^: prereq1 prereq2 ...
Of course duplicate entries are ignored. One problem can be triggered if m4 is used like:
target : prereq1
do_something $< | m4 >$@
in this case the user should tell m4 which file originates its stdin and this feature is actually missing in my patch, but it's quite trivial to add it - won't be a problem.
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"
Regardless of other considerations, this is the standard practice with GCC and I would just want M4 to work with the same legacy.
You can always alias "m4" to "m4 > /dev/null" to produce only dependencies and suppress stdout.
Best Regards,
Lorenzo