[Scons-dev] Possible minor bug + how to get (or assign) a builder to a file node?

[Left Right]

> 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 misbehaviour. But I'll get back there, when
I have a better understanding of what they do.
The example given in the link is unrealistically simple... for
example, the pseudo-builder assumes there always will be source -
hence it is impossible to make a pseudo-builder that doesn't require
at least one argument :| (this is becuase of how
MethodWrapper.__call__() works)

Best.

Oleg