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 <[email protected]> wrote: > Well said Dirk! > +1 > > On Sun, Nov 2, 2014 at 4:25 AM, Dirk Bächle <[email protected]> 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 <[email protected]> >>> 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 >> [email protected] >> https://pairlist2.pair.net/mailman/listinfo/scons-dev >> > > > _______________________________________________ > Scons-dev mailing list > [email protected] > https://pairlist2.pair.net/mailman/listinfo/scons-dev > >
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
