I'd almost say we should through an exception when a sideffect file is
specified as a source (for any builder)
-Bill
On Sat, Nov 1, 2014 at 4:03 AM, Gary Oberbrunner <ga...@oberbrunner.com>
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.
>
> 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 <wblevins...@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 <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
> >
>
>
>
> --
> Gary
> _______________________________________________
> 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
