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 <b...@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 <tshor...@gmx.de> wrote: > >> On 31.10.2014 20:04, Gary Oberbrunner wrote: >> >>> On Fri, Oct 31, 2014 at 2:55 PM, Dirk Bächle <tshor...@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@scons.org >> https://pairlist2.pair.net/mailman/listinfo/scons-dev >> > > > _______________________________________________ > Scons-dev mailing list > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > >
_______________________________________________ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev