Re: a syntax for multitarget rules

[Britton Kerin]

On Fri, Nov 14, 2014 at 8:34 PM, Tim Murphy <address@hidden> wrote:
> Hi :-)

Hello :)

> On 14 November 2014 19:31, Britton Kerin <address@hidden> wrote:
>>
>> On Fri, Nov 14, 2014 at 1:35 AM, Tim Murphy <address@hidden> wrote:
>> > To save typing here's an example of some of the possible hacks:
>> > http://www.cmcrossroads.com/article/rules-multiple-outputs-gnu-make
>> >
>> > You'll see the problem with "chaining" dependencies - there is a
>> > situation
>> > when a file is deleted and running make again doesn't recreate it.
>> > Basically only one target in your chain has a "command" or "recipe" so
>> > if
>> > that file exists then make won't run the recipe even if some other file
>> > in
>> > the chain is missing.
>>
>> So then the compiler tells you it isn't there.  Or if it's just existence
>> you
>> want to verify you can have make check for you as I showed in my previous
>> post
>> if you like that better.  So its really only useful in the fairly
>> pathological
>> case where one of the multiple outputs can be updated in some alternate
>> way
>> that make doesn't know about.  Even in this case you could then just use
>> directive or so and teach your build system about that alternate
>> mechanism.
>>
>> I can't believe its really worth a new feature for this.  The number
>> of combinations of different rule types/variable/expansions is already
>> significant.
>
>
> I'm not sure we've understood each other. without this feature the most
> obvious "fix" results in a potentially incorrect incremental build.   To one

Well, that's different than what I've heard so far, which was that the outputs
of a multi-output program might not be there.  I guess if that's going to
cause a subtle rather than an obvious build failure you definitely need to
check for their existence on the make side using the mechanism I suggested
two posts back.

If something else is tweaking (rather than just deleting) the output files
that are represented by the stamp, it is indeed harder to handle, though
I still maintain that in that case you effectively have multiple different
build paths and it should in theory be possible to represent them with make
conditionals, i.e. teach the build system about what's going on and when
and how to fire it off and make sure it updates the stamp when it does.

> person this may seem like a fantasy usecase - a corner case - but to someone
> like me who has had the problem it was nearly insoluble and I spent
> thousands of pounds worth of my time working out another solution for gmake
> (based on $shell and md5sum) that worked properly but was of tremendous
> intricacy and it was slow.  I think a little effort in make would have

Sounds like I don't understand the use case.  How do stamps that represent
the output file set fail, unless the files are being changed by some mechanism
that make isn't aware of?

> helped me and other people and at the time I again couldn't do it for
> another stupid reason.
>
> Look at it this way: do each of us use every feature in make? I think its'

No we don't, and it would be nice if a lot of them could go away -- they bloat
make painfully for little real modern-world benefit (e.g. most if not all of
the implicit rules, archive rules, VPATH).  Once you put something in make
you can never take it out or change it, because some build system somewhere
is using it.  So its worth asking if its worth it before you add things.

> unlikely. So should all the features one of us doesn't use get deleted?  I
> imagine not.  Hence if you haven't had problems with this issue then why
> bother to nix it for people who do?

It might be worth it, I don't claim to know for sure and its definitely not my
decision.  I just suspect that it's enough of a corner case that the pain for
implementers and other users trying to get a handle on the already-complicated
collection of different rule types could easily be greater overall.  I like
make and don't think all possible features are guaranteed to be beneficial,
so I bother to post.

Britton