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

[William Blevins]

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
> <http://www.scons.org/doc/production/HTML/scons-user.html#f-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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20141031/1c19859f/attachment-0001.html>