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

[Bill Deegan]

Well said Dirk!
+1

On Sun, Nov 2, 2014 at 4:25 AM, Dirk Bächle <tshortik at gmx.de> wrote:

> 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
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20141102/b4519d56/attachment.html>