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
