Re: [Scons-dev] Likely bug - installing side effect files
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 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 [...] 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 Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Likely bug - installing side effect files
Well said Dirk! +1 On Sun, Nov 2, 2014 at 4:25 AM, Dirk Bächle tshor...@gmx.de 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 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 [...] 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 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
Re: [Scons-dev] Likely bug - installing side effect files
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 b...@baddogconsulting.com wrote: Well said Dirk! +1 On Sun, Nov 2, 2014 at 4:25 AM, Dirk Bächle tshor...@gmx.de 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 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 [...] 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 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
[Scons-dev] Question about binfo
I'm investigating the md5sum issue brought up by Priotr, and I have some questions about Node.changed behavior and binfo. It seems that Node.changed always gets called twice: once by taskmaster.prepare and once by the builder. Not sure why this happens twice, but binfo.[source,depends,implicit] elements are str types on the first round and Node types the second round. I'm confused as to why binfo contents change despite no change to any dependencies. The contents could be equivalent, but if you run SCons commands in different directories, then the path varies, so binfo as str types throws a wrench into dependency comparison. Without a guaranteed comparison method for previous/current dependencies (IE. disambiguate and a normalized path), then I don't this this can be fixed. Any thoughts? V/R, William ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Question about binfo
More information at http://scons.tigris.org/issues/show_bug.cgi?id=2980 V/R, William On Sun, Nov 2, 2014 at 2:55 PM, William Blevins wblevins...@gmail.com wrote: I'm investigating the md5sum issue brought up by Priotr, and I have some questions about Node.changed behavior and binfo. It seems that Node.changed always gets called twice: once by taskmaster.prepare and once by the builder. Not sure why this happens twice, but binfo.[source,depends,implicit] elements are str types on the first round and Node types the second round. I'm confused as to why binfo contents change despite no change to any dependencies. The contents could be equivalent, but if you run SCons commands in different directories, then the path varies, so binfo as str types throws a wrench into dependency comparison. Without a guaranteed comparison method for previous/current dependencies (IE. disambiguate and a normalized path), then I don't this this can be fixed. Any thoughts? V/R, William ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
