Re: [Scons-dev] Possible minor bug + how to get (or assign) a builder to a file node?
You can't stick a dictionary in a shell environment variable... Why would I want to pass dictionary to shell? I think about the build script as being a little program that is written in Python, not a list of commands to path to the shell. That's why I've chosen Python to begin with! It seems that you think that your build doesn't follow these rules, and as such want to build something else on top of SCons. If that's the case your path will be much more difficult (think square peg, round hole) Yes, it is different, of course it is! Is it entirely incompatible as you say?.. well, I need only very few things from SCons, and am willing to do the rest on my own, in the way I think better suits my needs, is that a crime? :) I'm absolutely not a Make person, I come from Ant / Maven background and think of building a project more in terms of those tools. I don't like Ant or Maven for not being real programming languages (writing more complex build scripts in either of them ends up in a lot of unrewarding labour, using low quality tools - no proper booleans, neither string manipulation, nor even math etc.) This is why Python. I used Python for writing little pre-processing scripts to build my own projects, but seeing how I'm repeating myself over and over again, I decided to invest more effort and make something reusable. Anyways, thank you for your patience, I'll try not to abuse it further! I agree with Bill; I don't think SCons as it exists now is going to serve your needs. It ought to be possible to build Flash with SCons ( http://www.wrwrwr.org/scons shows up when I google SCons flash) but I think you are looking for a type of process that is pretty different from how SCons is organized. I saw wrwrwr project, and that's why I decided to do it from scratch :) What that project is trying to do, is it's trying to do the compiler's job at locating the sources, for example. And it fails to do it at any non-trivial project. I mean, the compiler itself is too compilcated, to even try to predict what sources exactly will it use... But not only it is difficult, it is absolutely unnecessary... It can only handle some very small % of what compiler can do. I.e. you can barely pass a handful of options to the compiler by using it, while there's like ten times more, etc., etc. With all due respect, that project isn't usable as it is... Best. Oleg ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Possible minor bug + how to get (or assign) a builder to a file node?
SCons can do this for you..
You can use something like this for your action:
env['CCCOM'] = '${TEMPFILE($CC $_MSVC_OUTPUT_FLAG /c
$CHANGED_SOURCES $CFLAGS $CCFLAGS $_CCCOMCOM)}'
the ${TEMPFILE(?.)} will output the contents to a file to get around long
compile line issues.
Nope, that's not going to make it... the things to put into temp file
need a lot of parsing, you can't just concatenate that. It's going to
be couple hundreds lines of code. But I don't really need SCons to do
this for me. This is something I feel confident I can handle myself. I
would actually feel more comfortable doing this on my own. Is there a
reason why I shouldn't?
Here's an example of the file I'll have to generate:
http://opensource.adobe.com/svn/opensource/flex/sdk/trunk/frameworks/flex-config.xml
You should read this section:
http://scons.org/doc/production/HTML/scons-user/c2092.html
OK... now I see where the misunderstanding comes from. Well, I don't
need this! :) I'll try to explain.
I've chosen specifically SCons because it is written in Python. Python
ideologically and syntactically is similar to AS (the language used in
Flash). It is way more convenient to use Python to write build
scripts, then say, Ant or Maven (at least for someone who uses Flash).
Hold on. Most people who will be building the projects are programmers
themselves, they are not users who need to build and install the
software, like one would do with configure - make - make install
process. Most of what comes out of Flash aren't programs (they are web
applets), while there are few options to produce desktop applications,
those are rare, and most of the times, users will get a compiled
binary + installer and never build it on their own.
This means that the use case of specifying additional options on the
command line will be vanishingly rare / I don't even expect anyone to
do it! What is most likely to happen is that users of the tool will
write more elaborate build scripts, with a lot of custom Python code.
So, I don't need / am not interested that much in reading command line
options beyond what's already in place - no *real* user will ever use
the program in that way. What I need is a comfortable interface for
specifying the option in the build script. And, in my humble opinion,
env. = Environment(variables = Variables(bar))
is better then
env['FOO'] = bar
which is still better then
env['ENV']['FOO'] = bar
Mainly because the first one allows documentation, and the second one
is shorter.
That's fine when compiling on the command line manually, but doesn't really
scale to a repeatable process doe it?
You need to think in terms of sources and targets, and flags which affect the
generation of the command line.
So if it's common for a user to specify --include-library, then you might
make a variable FLEX_INC_LIBS, which then get's expanded using probably
_concat
(Here's an example from Default.py)
'_LIBFLAGS' : '${_concat(LIBLINKPREFIX, LIBS, LIBLINKSUFFIX,
__env__)}',
Not a chance someone will call the build tool specifying these options
every time on the command line! Not even once! :D I wasn't even
imagining anything like that. In my ideal situation the build will
look like so:
env = Environment(tools = ['scons-flash'],
ENV = {'FLEX_HOME' : '/home/wvxvw/Projects/Flex/4.6/'
'MXMLC_OPTIONS' : { 'debug': True, ...
'compiler' : { 'keep': True, ...
'fonts' : {
'font-manager': Blah ... )
env.Swf(source='./src/tests/Test.as',
target='./bin/Test.swf',
override_compiler_options = { ... })
I sure want to avoid having to interpolate options into strings. I.e.
'$OPTION=value' is not good. The example below should illustrate what
I would expect from users to be doing, when they need to include
something.
def gen_includes():
for (dirpath, dirnames, filenames) in os.walk(only_user_knows_where):
directories = [d for d in dirnames if should_inculde(d)]
return directories
env.Flash(..., compiler_options = { 'include-library' : gen_includes() })
There's another particular inconvenience about options being strings
in that compiler doesn't follow GNU rules for short / long options and
how things should be read / understood. It's close, but it's
incorrect, and it will conflict with the common way to do that. I.e.
options never start with double hyphen, but there are short / long
options, and they both can be followed by either space or equals sign
(sometimes += too). That's something I'll have to parse on my own,
unfortunately.
http://scons.org/wiki/ToolsForFools
I've read that. Not meaning to criticize, there are some parts of
SCons code (I'm talking specifically about Action and perhaps
Executor), which are, erm... very hard to use in a different setting.
For the quick test it was easier to remove them, then to try to
understand the particular
Re: [Scons-dev] Possible minor bug + how to get (or assign) a builder to a file node?
Oleg,
On Oct 7, 2012, at 12:17 PM, Left Right olegsivo...@gmail.com wrote:
SCons can do this for you..
You can use something like this for your action:
env['CCCOM'] = '${TEMPFILE($CC $_MSVC_OUTPUT_FLAG /c
$CHANGED_SOURCES $CFLAGS $CCFLAGS $_CCCOMCOM)}'
the ${TEMPFILE(?.)} will output the contents to a file to get around long
compile line issues.
Nope, that's not going to make it... the things to put into temp file
need a lot of parsing, you can't just concatenate that. It's going to
be couple hundreds lines of code. But I don't really need SCons to do
this for me. This is something I feel confident I can handle myself. I
would actually feel more comfortable doing this on my own. Is there a
reason why I shouldn't?
Here's an example of the file I'll have to generate:
http://opensource.adobe.com/svn/opensource/flex/sdk/trunk/frameworks/flex-config.xml
You should read this section:
http://scons.org/doc/production/HTML/scons-user/c2092.html
OK... now I see where the misunderstanding comes from. Well, I don't
need this! :) I'll try to explain.
I've chosen specifically SCons because it is written in Python. Python
ideologically and syntactically is similar to AS (the language used in
Flash). It is way more convenient to use Python to write build
scripts, then say, Ant or Maven (at least for someone who uses Flash).
Hold on. Most people who will be building the projects are programmers
themselves, they are not users who need to build and install the
software, like one would do with configure - make - make install
process. Most of what comes out of Flash aren't programs (they are web
applets), while there are few options to produce desktop applications,
those are rare, and most of the times, users will get a compiled
binary + installer and never build it on their own.
This means that the use case of specifying additional options on the
command line will be vanishingly rare / I don't even expect anyone to
do it! What is most likely to happen is that users of the tool will
write more elaborate build scripts, with a lot of custom Python code.
So, I don't need / am not interested that much in reading command line
options beyond what's already in place - no *real* user will ever use
the program in that way. What I need is a comfortable interface for
specifying the option in the build script. And, in my humble opinion,
env. = Environment(variables = Variables(bar))
is better then
env['FOO'] = bar
which is still better then
env['ENV']['FOO'] = bar
Mainly because the first one allows documentation, and the second one
is shorter.
That's fine when compiling on the command line manually, but doesn't really
scale to a repeatable process doe it?
You need to think in terms of sources and targets, and flags which affect
the generation of the command line.
So if it's common for a user to specify --include-library, then you might
make a variable FLEX_INC_LIBS, which then get's expanded using probably
_concat
(Here's an example from Default.py)
'_LIBFLAGS' : '${_concat(LIBLINKPREFIX, LIBS, LIBLINKSUFFIX,
__env__)}',
Not a chance someone will call the build tool specifying these options
every time on the command line! Not even once! :D I wasn't even
imagining anything like that. In my ideal situation the build will
look like so:
env = Environment(tools = ['scons-flash'],
ENV = {'FLEX_HOME' : '/home/wvxvw/Projects/Flex/4.6/'
'MXMLC_OPTIONS' : { 'debug': True, ...
'compiler' : { 'keep': True, ...
'fonts' : {
'font-manager': Blah ... )
You can't stick a dictionary in a shell environment variable..
env.Swf(source='./src/tests/Test.as',
target='./bin/Test.swf',
override_compiler_options = { ... })
I sure want to avoid having to interpolate options into strings. I.e.
'$OPTION=value' is not good. The example below should illustrate what
I would expect from users to be doing, when they need to include
something.
def gen_includes():
for (dirpath, dirnames, filenames) in os.walk(only_user_knows_where):
directories = [d for d in dirnames if should_inculde(d)]
return directories
env.Flash(..., compiler_options = { 'include-library' : gen_includes() })
There's another particular inconvenience about options being strings
in that compiler doesn't follow GNU rules for short / long options and
how things should be read / understood. It's close, but it's
incorrect, and it will conflict with the common way to do that. I.e.
options never start with double hyphen, but there are short / long
options, and they both can be followed by either space or equals sign
(sometimes += too). That's something I'll have to parse on my own,
unfortunately.
http://scons.org/wiki/ToolsForFools
I've read that. Not meaning to criticize, there are some parts of
SCons code
Re: [Scons-dev] Possible minor bug + how to get (or assign) a builder to a file node?
On Sun, Oct 7, 2012 at 3:17 PM, Left Right olegsivo...@gmail.com wrote: The example given in the link is unrealistically simple... for example, the pseudo-builder assumes there always will be source - Because SCons builds a DAG and then uses it to find out what needs to be rebuilt, any builder always needs a source. Otherwise it would run every time. I agree with Bill; I don't think SCons as it exists now is going to serve your needs. It ought to be possible to build Flash with SCons ( http://www.wrwrwr.org/scons shows up when I google SCons flash) but I think you are looking for a type of process that is pretty different from how SCons is organized. -- Gary ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Possible minor bug + how to get (or assign) a builder to a file node?
On Oct 6, 2012, at 11:54 AM, Left Right olegsivo...@gmail.com wrote:
Please respond to questions in line rather than a big blob at the end of the
message filled with questions.
Sorry, it probably depends on the mail client you are using. But I'll
try to improve, we'll see if it's any better.
On Oct 5, 2012, at 7:59 AM, Left Right olegsivo...@gmail.com wrote:
- provide an additional (xml) file with settings (that's how I'm going
to go about compilation).
Does this file have a static name and/or belong in a fixed place relative to
the source file or the project file?
(In essence this file becomes a source, since changing it should cause a
recompile)
Erm... no, it's been deleted right after the compiler finishes. I'm
creating it only because constructing a command in the command line
may overload the command line. Perhaps in the future I'll have a
wrapper for the compiler to communicate to it directly, and this file
will not be needed.
SCons can do this for you..
You can use something like this for your action:
env['CCCOM'] = '${TEMPFILE($CC $_MSVC_OUTPUT_FLAG /c $CHANGED_SOURCES
$CFLAGS $CCFLAGS $_CCCOMCOM)}'
the ${TEMPFILE(….)} will output the contents to a file to get around long
compile line issues.
- specify these settings on command line when calling the compiler (in
the worst case you risk to overload the command line, it may easily
get too long).
This wouldn't apply to a SCons build right? You might specify FLEX_FLAGS or
something like that that the user my alter in their scons logic.
Yes, this is what I wanted to get from Environment (Variables, or
whichever other way is best), or have some defaults. I'm not sure how
to answer about SCons build. It will only affect my extension code.
You should read this section:
http://scons.org/doc/production/HTML/scons-user/c2092.html
- read some of them from the source code - there are some particular
compiler metadata that instructs it about project settings / parts
(none of my concerns, the compiler will do here on its own)
Does this impact the generated files from such a source file? (Does it
change the name or produce more or less files?)
Yes, it does, here's a very basic example:
package {
[SWF(name=something.swf)]
class X extends Sprite { ... }}
This is how source code may look, and, let's say this file is called
something_else.as. The compiler will generate something.swf from it.
It can also cause more files to be produced (if it infers something is
a module, then it will compile it into a separate binary). I can't
think of a situation when there will be less files generated.
O.k. So you'll likely need a scanner and/or an emitter for your builder.
So it parses the sources looking for info on it's dependencies?
It's not that simple... some times you need to help it. I.e. you may
force including a source, which isn't referenced directly from code,
or you may ask it to not link statically a particular source, because
you will provide it at runtime. And, in case when you compile a
library, you will most certainly be looking for the list of sources on
your own (just list all sources in a directory is what will do in most
cases).
How do you Help? How do you force including a source,etc.. (as you
state above)
There are many ways, but few common ones would be:
$ mxmlc other argumens -include-library lib0.swc -include-library lib1.swc
...
where mxmlc is the compiler and -nclude-library tells it to include
the entire library, similarly, it can be -include-class, -include-file
and perhas there's some more...
It can also include locales, stylesheets, some XML settings files for
RPC... well, I'd need to search through the options to build an
exhaustive list.
The thing about it is that including libraries is usually simple: you
only need to know what's the name of the library, and there aren't
many. But when including separate classes, you would need some
scripting help, because there will be tents or hundreds. One way of
doing it is by generating a manifest file, where all classes are
mentioned and give it to the compiler. It also knows how to handle
these particular files.
That's fine when compiling on the command line manually, but doesn't really
scale to a repeatable process doe it?
You need to think in terms of sources and targets, and flags which affect the
generation of the command line.
So if it's common for a user to specify --include-library, then you might make
a variable FLEX_INC_LIBS, which then get's expanded using probably _concat
(Here's an example from Default.py)
'_LIBFLAGS' : '${_concat(LIBLINKPREFIX, LIBS, LIBLINKSUFFIX, __env__)}',
Re' environment. I'm not sure yet... can I somehow make users create a
different environment, when they do Env()?
Not sure what you mean by this at all, can you restate it? (or clarify)
Can you paste some code for this so we can see what you're doing?
Hope that
Re: [Scons-dev] Possible minor bug + how to get (or assign) a builder to a file node?
1. What are your inputs? 2. What are your outputs? 3. How do you determine flags for compiling? Based on your previous emails: the compiler does almost all the job, it find the required sources by inferring from the code what it should be looking for So it parses the sources looking for info on it's dependencies? For instance, the compiler has a concept of modules, so it would compile a group of files, and then would compile a module using the first group in a similar way you'd use headers in C, when linking dynamic libraries. How does it determine the modules? Step 1: I've overridden _execute in FlashBuilderBase in order to be able to gather some important information about the project (often times Flash comes with Eclipse-style project files, so I'm parsing the project file, and interpret the information I find in it in a way it will be useful later during the build). Is the project file for all sources you're trying to compile, or per module, or some other grouping? As Gary stated in another email, you probably can use a separate environment per group of code to get the appropriate flags to them. -Bill The inputs fall under 5 major categories: - Eclipse-style project -- Flash Builder project -- FDT project These are usually XML files that describe a project, they contain compilation settings, maybe for multiple sub-projects, this is more like SLN files in MSVS. So, I'm parsing these and trying to come up with a way to run the compiler (+ some other tools some times) to replicate what would IDE do during the compilation process. - FlashDevelop project This is similar to Eclipse projects except for there may be multiple projects in the same directory. - Single source file as an input (possible variants are *.as, *.mxml or *.css) - Multiple source files or a manifest containing a list of files to compile. - AIR project is a kind of project which uses a special manifest file. Using this manifest file it packages what was compiled from other sources. - Documentation generator, this is very similar to multi-source one. The outputs may be: - a single SWF or SWC files (an applet binary or a library) - multiple codependent SWFs or SWCs. - documentation (multiple HTML files) - AIR executables, Android installers and iOS installers Flags for compiling: The compiler comes with a file with most of the defaults set in some way, there are these possible ways to override these defaults: - provide an additional (xml) file with settings (that's how I'm going to go about compilation). - specify these settings on command line when calling the compiler (in the worst case you risk to overload the command line, it may easily get too long). - read some of them from the source code - there are some particular compiler metadata that instructs it about project settings / parts (none of my concerns, the compiler will do here on its own) - some, however very few can be set as environment variables, this is not an idiomatic way to do it, and only very few (basically, only the compiler location and some Java-related settings) can be set in this way - again, none of my concerns. The script would however very likely need to read the compiler location from user in some way - it's uncommon to install compiler on PATH / alias it for availability or similar. It is rather more common to have multiple version installed simultaneously. So it parses the sources looking for info on it's dependencies? It's not that simple... some times you need to help it. I.e. you may force including a source, which isn't referenced directly from code, or you may ask it to not link statically a particular source, because you will provide it at runtime. And, in case when you compile a library, you will most certainly be looking for the list of sources on your own (just list all sources in a directory is what will do in most cases). How does it determine the modules? It knows certain classes that extend certain other classes to be the modules. But this is a lot of parsing! I'm not doing it no way! :) But if it comes in a shape of Eclipse project, I'll have that info from the project settings. Is the project file for all sources you're trying to compile, or per module, or some other grouping? Well, there are different kinds of projects... FlashDevelop projects have only one target per project and don't define modules. Only FlashBuilder or FDT projects do. In all other cases users would have to mimic what projects do on their own. I.e. they would define two projects as depending on each other etc. There's a lot more stuff I hoped to do at some point (alternative compilers, linkers, transcoders etc) but I won't go into details now. Re' environment. I'm not sure yet... can I somehow make users create a different environment, when they do Env()? To be honest, I can't find a way to change anything about this object, I took it for granted that this is what I'm to deal with. I
Re: [Scons-dev] Possible minor bug + how to get (or assign) a builder to a file node?
On Thu, Oct 4, 2012 at 9:31 AM, Left Right olegsivo...@gmail.com wrote:
Builder.py:537
def _execute(self, env, target, source, overwarn={}, executor_kw={}):
# We now assume that target and source are lists or None.
if self.src_builder:
source = self.src_builder_sources(env, source, overwarn)
Hi. I've ran into this (what seems to be a bug) while trying to find
the builder of a created file node.
It looks like for you this test is never true. Because if the
src_builder was a builder object, it would be implementing a
__nonzero__ method, which throws:
InternalError: Do not test for the Node.builder attribute directly;
use Node.has_builder() instead
I ran into this eventually by trying to assign to src_builder property
of a builder (this is something where I'm blur, but can't find any
other way to link a file node to its builder). So that when I call
_execute, self.src_builder exists, but can't be used inside condition.
:|
I'm most certain I don't quite understand yet how exactly to do what I
need (so, I probably shouldn't even get there), just stumbled over
this thing by accident.
The question: suppose I have a generator function like this:
def asGenerator(source, target, env, for_signature):
print source: %s % source[0].get_path()
print abs dir: %s % source[0].src_builder
Suppose I have created a file node (which is source[0].get_path()) like so:
class FlashBuilderBase(BuilderBase):
An extension needed to run Flash() target with no arguments
def __init__(self, # long list of arguments...
**overrides):
self.fb_project_settings = None
self.fd_project_settings = None
return super(FlashBuilderBase, self).__init__(# same arguments
once again...
**overrides)
def _execute(self, env, target, source, overwarn={}, executor_kw={}):
# ...
self.fb_project = # some info I need about the project file ...
if not target:
target = # some code to find the target ...
if not source:
source = target # this is the file, which later becomes
the source[0] in asGenerator
return super(FlashBuilderBase, self)._execute(
env, target, source, overwarn, executor_kw)
Now, I have to get reference this builder (FlashBuilderBase) from
source[0] in asGenerator - how'd I do that?
You seem to be very confused, if you're that deep into the internals
and undocumented methods. :-)
Can you back up a few steps and say what you're trying to do? (Note
that you say you're creating a File Node, but the code you show is for
a subclass of Builder, which is pretty odd.) Have you been through
Chapter 18 of the User's Guide?
http://www.scons.org/doc/production/HTML/scons-user/c3621.html
--
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Possible minor bug + how to get (or assign) a builder to a file node?
Can you back up a few steps and say what you're trying to do? (Note that you say you're creating a File Node, but the code you show is for a subclass of Builder, which is pretty odd.) Have you been through Chapter 18 of the User's Guide? http://www.scons.org/doc/production/HTML/scons-user/c3621.html -- Gary Thanks for reply. I'm probably that deep because of a mismatch in the regular way C or Java projects are built vs Flash. The thing is, managing sources is very simple in Flash (the compiler does almost all the job, it find the required sources by inferring from the code what it should be looking for), but there are many configuration settings that one should pass to compiler, which are given per project, or per certain part of the project. So, I'm much more interested in having a reference to the builder in the generator function, then the source file names (I can obtain the reference to the source files at any time, actually, and it's not very important), but I need to somehow transfer a lot of information with the group of files. For instance, the compiler has a concept of modules, so it would compile a group of files, and then would compile a module using the first group in a similar way you'd use headers in C, when linking dynamic libraries. Anyways, I think I can better explain my problem in terms of the code, which isn't working quite as I'd need it to. Step 0: I've extended BuilderBase with FlashBuilderBase and added this builder to env[BUILDERS]. Step 1: I've overridden _execute in FlashBuilderBase in order to be able to gather some important information about the project (often times Flash comes with Eclipse-style project files, so I'm parsing the project file, and interpret the information I find in it in a way it will be useful later during the build). Step 2: This information is saved in a FlashBuilderBase field. Step 3: The overriden _execute() calls super(FlashBuilderBase, self)._execute() Step 4: BuilderBase._execute() at some point calls self.action.batch_key(env or self.env, tlist, slist) Step 5: batch_key() calls my generator function. In that generator function I must have a reference to the builder which submitted the source files, but I can't because it is only in Step 6: that BuilderBase._execute() calls t.builder_set(self) - and this is too late :( because in my generator function I needed that source.builder would give me the reference to FlashBuilderBase. If I try to circumvent this by either calling t.builder_set(FlashBuilderBaseInstance) before generator function is called, it enters an infinite loop (why - I don't know yet) Also, if I try, in FlashBuilderBase self.src_builder = [self] - this enters infinite loop too. I could find a solution by making generator function capture the builder instance I need to acces in it, but this is super convoluted, and it also means that I would need a function per builder (while it could've been more generic). What could've helped - is if BuilderBase._execute() called t.builder_set(self) before it calls self.action.batch_key(env or self.env, tlist, slist) Sorry for a very long message! ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Possible minor bug + how to get (or assign) a builder to a file node?
On Thu, Oct 4, 2012 at 1:03 PM, Left Right olegsivo...@gmail.com wrote:
Thanks for reply. I'm probably that deep because of a mismatch in
the regular way C or Java projects are built vs Flash. The thing is,
managing sources is very simple in Flash (the compiler does almost all
the job, it find the required sources by inferring from the code what
it should be looking for), but there are many configuration settings
that one should pass to compiler, which are given per project, or per
certain part of the project.
I don't know the details, but perhaps rather than overriding SCons
internals (which are subject to change), you could store all this
configuration in the Environment. Use a different Environment for
each project, or part of project. The builders can just use
$FLASH_XYZ to expand to whatever is different, because the environment
is remembered, and passed to the builder. Perhaps this is similar to
wanting to use a different C compiler for different parts of a
project? We do that, and just use different Environments to make it
work.
env1.Object('foo1', foo1_sources)
env2.Object('foo2', foo2_sources)
and so on.
In any case I don't think your step 0 is the right way to construct a
builder -- you should use the Builder() factory method.
--
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
