Re: [Scons-dev] Likely bug - installing side effect files
Hi there, On 30.10.2014 16:01, Ben Golding wrote: Thanks Gary. http://scons.tigris.org/issues/show_bug.cgi?id=2982 I started to add some additional trace to Taskmaster.py, and compare the logs from sequential vs. parallel builds. The bug seems to relate to how the node states are used for the side-effect nodes: - In executed_with_callbacks(), the side-effect state is set to NODE_NO_STATE. - In postprocess(), the logic to decrement the parent ref count is only active for a side-effect node with state NODE_EXECUTING. Although this helped me to understand the bug a bit better, I'm not sure what is the correct fix. 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. Just my 2 cents. Best 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
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. -- Gary ___ 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
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
Re: [Scons-dev] Likely bug - installing side effect files
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
