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

[Gary Oberbrunner]

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.

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.

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
>
>> SideEffect(side_effect, target) , env.SideEffect(side_effect, target)
>> Declares side_effect as a side effect of building target. Both side_effect
>> and target can be a list, a file name, or a node. A side effect is a target
>> file that is created or updated as a side effect of building other targets.
>> For example, a Windows PDB file is created as a side effect of building the
>> .obj files for a static library, and various log files are created updated
>> as side effects of various TeX commands. If a target is a side effect of
>> multiple build commands, scons will ensure that only one set of commands is
>> executed at a time. Consequently, you only need to use this method for
>> side-effect targets that are built as a result of multiple build commands.
>> Because multiple build commands may update the same side effect file, by
>> default the side_effect target is not automatically removed when the target
>> is removed by the -c option. (Note, however, that the side_effect might be
>> removed as part of cleaning the directory in which it lives.) If you want to
>> make sure the side_effect is cleaned whenever a specific target is cleaned,
>> you must specify this explicitly with the Clean or env.Clean function.
>
>
> Reading the description, I think that the SideEffect behavior doesn't cover
> the Depends behaviors which Andrew desires.
>
> V/R,
> William
>
> On Fri, Oct 31, 2014 at 7:22 PM, Bill Deegan <bill at baddogconsulting.com>
> wrote:
>>
>> SideEffect() by definition (to me at least) should be informing SCons that
>> a file is produced, but it is not important.  Allowing SCons to be aware of
>> it.
>>
>> It seems like using that file as an input in any part of your build would
>> violate such an idea.
>> So I think I'm agreeing with Dirk on this one.
>> Regardless of however the code might be defined today. I think it's
>> important to be able to tell SCons about such a type of file.
>>
>> -Bill
>>
>> On Fri, Oct 31, 2014 at 12:20 PM, Dirk Bächle <tshortik at gmx.de> wrote:
>>>
>>> On 31.10.2014 20:04, Gary Oberbrunner wrote:
>>>>
>>>> On Fri, Oct 31, 2014 at 2:55 PM, Dirk Bächle <tshortik at gmx.de> wrote:
>>>>>
>>>>> I don't think there is anything to fix here...and it's no bug for me
>>>>> either.
>>>>> Please read the man page for the definition
>>>>> of a SideEffect, and when it should be used. My understanding is, that
>>>>> in
>>>>> your case the conditions do not apply...so you should rather define an
>>>>> Emitter (see http://www.scons.org/wiki/ToolsForFools for example) that
>>>>> adds
>>>>> "sf0" and "sf1" to the list of targets.
>>>>> Then the Install() should work as expected.
>>>>
>>>> I disagree.  He's explicitly passing the files in sf to Install();
>>>> Install() should always (try to) install all the files given as its
>>>> sources.  Whether they're created as side effects or anything else
>>>> _shouldn't_ matter.
>>>>
>>> Hmm, do you mean "all files" or "all targets"? I really don't regard
>>> SideEffects to be full targets...but maybe I'm overlooking something. I'm
>>> just thinking about the case where I use a "foo" compiler. It always creates
>>> a file "named.fix", containing some internal info that's input for the build
>>> step itself.
>>> So, for scheduling single builds with this compiler correctly, in
>>> concurrency speak: locking it with a kind of monitor for parallel mode, I
>>> define the file "named.fix" as SideEffect in my "foo" Builder.
>>> If I then say something like:
>>>
>>>   env = Environment(tools=['foo'])
>>>   a = env.Foo('a.foo','a.in')
>>>   b = env.Foo('b.foo','b.in')
>>>
>>>   env.Install('/install', [a, b, 'named.fix'])
>>>
>>> which version of "named.fix" gets installed? Which version *should* get
>>> installed? And is the intended ordering guaranteed for any invocation of "-j
>>> n"?
>>> You're probably right, but the above is what's rolling through my head
>>> right now...all kinds of clarifications and comments are welcome. ;)
>>>
>>> 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
>>
>
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>



-- 
Gary