[Scons-dev] Likely bug - installing side effect files

[Dirk Bächle]

Gary,

On 01.11.2014 12:03, Gary Oberbrunner wrote:
> SideEffect may be the root cause of the problem, but Install should
> not behave this way, IMHO.  If you pass some nodes to Install, it
> should either install them or fail the build with an error ("don't
> know how to build..." or similar).  It shouldn't ever _not_ install
> them silently.
I gave this some more thought, and when we talk about "proper" targets, 
or source files that always exist, I agree with you. Install should just 
work...
However, a file marked as SideEffect is a different story... And that's 
because it has a fixed name, but can have different contents... 
depending on whether you're currently building "a.foo" or "b.foo", as 
introduced in my last example. This means that if we supported it as 
"full" target, we would soon run into trouble with things like:

   scons a.foo b.foo install

vs.

   scons b.foo a.foo install

. We're primarily a build system, not an install system, and care about 
secure and stable builds...which also should include convergence at the 
top of our priority list. With this I mean, that a user expects that the 
build "converges" to a settled state (I do, at least), where all targets 
are properly updated...independent of the order in which the single 
build steps for the targets are executed.
And it's obvious to me that we'd start violating this principle, when 
treating SideEffects as fully equivalent targets.
> Arguing against myself :-), we could change the doc for SideEffect to
> indicate that nodes that are SideEffects are not guaranteed to be
> created, and may or may not be ignored by targets that use them as
> sources.  But, this kind of indeterminacy doesn't seem like a good
> user experience to me.
The problem I described above, doesn't yield a good user experience 
either... ;)

In my opinion, this is the point where we have to educate (horrible 
word, but I can't think of a better term right now)
the user to not use SideEffect as a workaround for properly defining a 
Builder/Emitter instead.

SideEffect should be reserved for files that only the compiler (or any 
other build step) cares about.

If the *user* cares about a target file, and wants to "work" with it in 
the DAG---by using it as input file to another build step for 
example---he has to define it as a "proper" target (=Emitter).

> On Fri, Oct 31, 2014 at 7:42 PM, William Blevins <wblevins001 at gmail.com> wrote:
>> Team,
>>
>> Not to be contrary here, but I think personal opinions should be postponed
>> until we determine if the definition of SideEffect per the SCons User Guide
>> matches the actual behavior.
>>
>> http://www.scons.org/doc/production/HTML/scons-user.html
>>
>>> [...]
>>>
>>
>> Reading the description, I think that the SideEffect behavior doesn't cover
>> the Depends behaviors which Andrew desires.
I agree, in the sense that the usage of SideEffect is simply the wrong 
approach for this use case. From my angle, the documentation matches the 
current behaviour just fine... However, it's probably a good idea to 
make it more clear that defining a SideEffect file means that the "user 
doesn't care" about what happens with the file. So, he can't rely on the 
file to be properly updated, or have a determined content at a given 
time. Therefore, he also can't Install/Copy/OtherBuilder() the 
file...because its contents are actually unknown.

So much for my latest thoughts about this, I hope they make some sense.

Regards,

Dirk