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

[William Deegan]

Oleg,


On Oct 7, 2012, at 12:17 PM, Left Right <olegsivokon at 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 (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)




All builds have some things in common
1. Specifying a list of targets and the sources they depend on. (Sometimes the list of sources can be derived or added to based on other sources and/or config type files)
2. Specifying how to translate one file type to another (compile,link,etc..)
3. Building a DAG to keep track of the big picture
4. Executing the Actions specified in #2 via a shell or as a subprocess using the DAG to decide which Actions need to be executed when.

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)

Good luck! I've run out of time to support your effort.

_Bill