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
