Re: Dependency flaw in cons (and scons) ?

[Steven Knight]

> But today when I thought about how rules with multiple targets
> ought to be handled, it suddenly struck my mind that maybe Cons
> fails to do the right thing in at least one case. I opened my Emacs
> and typed the following Construct file:
> 
>       #---------------------------------------
>       $e = cons->new();
> 
>       $e->Command( ['xxx', 'yyy'], 'aaa',
>                    "/usr/bin/echo xxx-content > xxx\n".
>                    "/usr/bin/echo yyy-content > yyy\n" );
> 
>       $e->Command('zzz', 'yyy', "/usr/bin/cp %< %>");
>       #---------------------------------------
        .
        .
        .
> But now suppose I change my mind and want 'zzz' to be made from
> 'xxx' instead of from 'yyy'. So I change the last 'Command' in the
> Construct file to:
> 
>       $e->Command('zzz', 'xxx', "/usr/bin/cp %< %>");
> 
> and rerun cons:
> 
>       $ cons zzz
>       cons: "zzz" is up-to-date.
>       $ cat zzz
>       yyy-content
> 
> Quite weird, isn't it ???

Yes, especially if you've never looked at that section of code.  Because
all of the targets ('xxx' and 'yyy') are built from the same command,
Cons gives all of them the same build signature.  So you can switch
between 'xxx' and 'yyy' as input to other builds, and have Cons think,
incorrectly, that everything is up-to-date.

(Interestingly enough, if you configure the SIGNATURE calculation so
that it uses the content signature of both 'xxx' and 'yyy', I'll bet it
will work properly and rebuild 'zzz'.)

> Just out of curiosity, I also wrote a similar "SConstruct" for
> SCons, and got the same (as I think) erroneous behaviour
> (this was my first attempt to use SCons, so I'm not 100% sure that I
> used it the right way; but it at least seems to behave exactly as
> Cons in this case).

I'd have been surprised if it behaved differently.  SCons borrowed its
multiple-target logic from Cons.

> Even before this incident, I have considered the way Cons handles
> rules with multiple targets, as rather "cludgy". So I was a bit
> surprised to see that SCons works the same way (as it appears to me
> at least).

Yeah, it essentially considers the first target in the list as the
"main" target and everything else is kind of along for the ride.

> It would be interesting to hear what others think about this.
> Is it a flaw ?

Most definitely.

> And how should it work instead ?

It should rebuild when you change from one input file to another.

> And implemented how ?

The build::multi package should generate different build signatures
for the individual targets in the list.  This would probably be in the
scriptsig subroutine.  Then other targets using those signatures would
get the right change information if either the command or the file
changed.

        --SK