[bug #42599] .RECIPEPREFIX should not have to be at beginning of line
Follow-up Comment #1, bug #42599 (project make): FYI, .RECIPEPREFIX was added in GNU make 3.82. I agree the error message is incorrect. In fact we shouldn't even be making that extra check in the case where RECIPEPREFIX is set. I'm not sure I agree with the preceding whitespace request though. This adds a lot of possibility for error into the parsing: if your recipe prefix happens to match some character at the beginning of the line for example. What about this: .RECIPEPREFIX = | all: | find . -type f ... \ | xargs grep -lv foobar | while read f; do echo file: $$f; done See the missing backslash at the end of the xargs line? Currently make will fail because it cannot parse the while line (no RECIPEPREFIX). If we allow leading whitespace then that looks like a recipe line and make will run it... and hang forever because the read is trying to read from stdin. The rule for recipe prefixes is currently very simple: check the single first character on the line and see if it's the recipe introduction character. Adding the ability to precede it with whitespace is something I'd have to think very carefully about. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42599 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #42599] .RECIPEPREFIX should not have to be at beginning of line
Follow-up Comment #2, bug #42599 (project make): Yeah, I realized later that there is an ambiguity problem. The obvious answer is to allow the prefix char if it is preceded by exactly the same whitespace as the rule line. I think that's worthwhile. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42599 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Question about pattern rule with multiple targets
On page 120 of the gnumake manual, it mentions support for pattern rules with multiple targets. This pattern rule has two targets: %.tab.c %.tab.h: %.y bison -d $ So, if I have a simple rule that looks like: %.bar1 %.bar2 : %.foo touch $(*F).bar1 touch $(*F).bar2 and then do: touch a.foo make a.bar1 touch a.bar1 touch a.bar2 make a.bar1 make: 'a.bar1' is up to date. rm a.bar2 make a.bar1 make: 'a.bar1' is up to date. make a.bar2 touch a.bar1 touch a.bar2 What I was really hoping is that make would consider both a.bar1 and a.bar2 to be required outputs of the rule and if one of them is deleted, then both the .bar1 and .bar2 targets should be considered out-of-date. But when I manually remove the a.bar2 file, the a.bar1 file is still considered to be up-to-date. Yet, when I then ask to build the a.bar2 target, both the a.bar1 and a.bar2 targets are re-built. Is there any way to code a rule so that all targets must always be considered to have been built simultaneously. More so, if after the deletion of the a.bar2 file, some other rule that depends on a.bar1 file would cause make to consider both the a.bar1 and a.bar2 files to be out-of-date. I really hope there is some way to support my need for a recipe to build all specified targets and have subsequent rules that depends on any one or more of those targets thus force the re-build of said targets if any of them are missing. Thanks, -Tom ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Question about pattern rule with multiple targets
On Fri, Jun 27, 2014 at 11:24 AM, Tom Varga tomva...@gmail.com wrote: On page 120 of the gnumake manual, it mentions support for pattern rules with multiple targets. This pattern rule has two targets: %.tab.c %.tab.h: %.y bison -d $ So, if I have a simple rule that looks like: %.bar1 %.bar2 : %.foo touch $(*F).bar1 touch $(*F).bar2 and then do: touch a.foo make a.bar1 touch a.bar1 touch a.bar2 make a.bar1 make: 'a.bar1' is up to date. rm a.bar2 make a.bar1 make: 'a.bar1' is up to date. make a.bar2 touch a.bar1 touch a.bar2 What I was really hoping is that make would consider both a.bar1 and a.bar2 to be required outputs of the rule and if one of them is deleted, then both the .bar1 and .bar2 targets should be considered out-of-date. But when I manually remove the a.bar2 file, the a.bar1 file is still considered to be up-to-date. Yet, when I then ask to build the a.bar2 target, both the a.bar1 and a.bar2 targets are re-built. Umm, why isn't this solved by having a correct dependency on a.bar2 where necessary? Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Question about pattern rule with multiple targets
b.zoo1 really only depends on b.bar1 b.zoo2 really only depends on b.bar2 However, only one rule (and tool) is used to build both b.bar1 and b.bar2 I really don't want force b.zoo1 to artificially depend on b.bar2 as it's not a real dependency. I was really just hoping to be able to convince gnumake that b.bar1 and b.bar2 are built with the same rule and MUST be consistent, that is both having been built at the same time and that both exist too. On Fri, Jun 27, 2014 at 5:34 PM, Philip Guenther guent...@gmail.com wrote: On Fri, Jun 27, 2014 at 11:24 AM, Tom Varga tomva...@gmail.com wrote: On page 120 of the gnumake manual, it mentions support for pattern rules with multiple targets. This pattern rule has two targets: %.tab.c %.tab.h: %.y bison -d $ So, if I have a simple rule that looks like: %.bar1 %.bar2 : %.foo touch $(*F).bar1 touch $(*F).bar2 and then do: touch a.foo make a.bar1 touch a.bar1 touch a.bar2 make a.bar1 make: 'a.bar1' is up to date. rm a.bar2 make a.bar1 make: 'a.bar1' is up to date. make a.bar2 touch a.bar1 touch a.bar2 What I was really hoping is that make would consider both a.bar1 and a.bar2 to be required outputs of the rule and if one of them is deleted, then both the .bar1 and .bar2 targets should be considered out-of-date. But when I manually remove the a.bar2 file, the a.bar1 file is still considered to be up-to-date. Yet, when I then ask to build the a.bar2 target, both the a.bar1 and a.bar2 targets are re-built. Umm, why isn't this solved by having a correct dependency on a.bar2 where necessary? Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Question about pattern rule with multiple targets
I guess this bug is pretty much what I'm dealing with. However, it also exhibits itself even when not using pattern rules. ie : b.foo : touch b.foo b.bar1 b.bar2 : b.foo touch b.bar1 touch b.bar2 b.zoo1 : b.bar1 touch b.zoo1 b.zoo2 : b.bar2 touch b.zoo2 The fact that b.bar1 and b.bar2 aren't forced to be consistent (built and exist at the same time) makes it nearly impossible to use gnumake in an engineering workflow where most tools output more than one target and yet downstream tools may only depend on a subset of those targets. What would be the likelihood of there being a fix to this issue in the latest 4.0 release? And, if it is, when might that be possible? Thanks, -Tom On Fri, Jun 27, 2014 at 5:43 PM, Paul Smith p...@mad-scientist.net wrote: On Fri, 2014-06-27 at 14:20 -0400, Tom Varga wrote: If there is a more appropriate forum for asking gnumake questions, please let me know. However, I'm hoping that this is a short enough question, that you might be able to quickly answer it for me. It's best to use either bug-make@gnu.org or help-m...@gnu.org rather than email me directly. %.bar1 %.bar2 : %.foo touch $(*F).bar1 touch $(*F).bar2 touch a.foo make a.bar1 touch a.bar1 touch a.bar2 make a.bar1 make: 'a.bar1' is up to date. rm a.bar2 make a.bar1 make: 'a.bar1' is up to date. make a.bar2 touch a.bar1 touch a.bar2 What I was really hoping is that make would consider both a.bar1 and a.bar2 to be required outputs of the rule and if one of them is deleted, then both the .bar1 and .bar2 targets should be considered out-of-date. I believe it's supposed to work this way, but there's a bug; I think it's https://savannah.gnu.org/bugs/?12078 Unfortunately it got lost on the stack for a really long time as you can see. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Question about pattern rule with multiple targets
On Fri, Jun 27, 2014 at 2:52 PM, Tom Varga tomva...@gmail.com wrote: b.zoo1 really only depends on b.bar1 b.zoo2 really only depends on b.bar2 However, only one rule (and tool) is used to build both b.bar1 and b.bar2 I really don't want force b.zoo1 to artificially depend on b.bar2 as it's not a real dependency. I was really just hoping to be able to convince gnumake that b.bar1 and b.bar2 are built with the same rule It works just fine for that! and MUST be consistent, that is both having been built at the same time and that both exist too. Ah, *this* is the issue, the fact that you can't use generated files from different runs. For most(?) program that generate multiple files, mixing and matching isn't an issue when the source file is unchanged. If the source file is changed, then make's current bits handle it just fine, rebuilding both, of course. There's certainly some way to express the if the either file is missing, rebuild both using $(if) and $(wildcard) to check for existence, but my reaction right now is fix the tool that isn't generating consistent output... Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Buffer overflow in orig/implicit.c
Kindly consider my fix for the lack of bounds checks in implicit.c Index: make-3.82/implicit.c === --- make-3.82.orig/implicit.c +++ make-3.82/implicit.c @@ -488,6 +488,9 @@ pattern_search (struct file *file, int a dir = pathdir; } + if (stemlen = PATH_MAX) + fatal (NILF, _(File name too long)); + DBS (DB_IMPLICIT, (_(Trying pattern rule with stem `%.*s'.\n), (int) stemlen, stem)); Thanks. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make