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
