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

[William Blevins]

I agree with Dirk here.

If multiple actions can have the same side-effect files, then Install
cannot have a "correct" behavior.  The behavior will always be ambiguous.

If the files are always unique to the build actions, then they are not
side-effects at all and should be correctly added to an emitter.

V/R,
William

On Sun, Nov 2, 2014 at 2:30 PM, Bill Deegan <bill at baddogconsulting.com>
wrote:

> 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
>>
>
>
> _______________________________________________
> 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/b2af8010/attachment-0001.html>