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

[William Deegan]

On Oct 6, 2012, at 11:54 AM, Left Right <olegsivokon at 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 <olegsivokon at 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 helps!

>> -Bill

> 

> I've uploaded some code but, beware, it's REALLY UGLY :) Sorry, I had

> to emphasize it. This is because I'm trying to understand how it

> works, and by no means I'm not going to keep it like that.

> So, here it is: https://code.google.com/p/scons-flash/


Looks like you really need to read: http://scons.org/wiki/ToolsForFools if you haven't already.
Your code is touching way to much SCons internals.

Looks like you really have 6 builders:

    env.Append(BUILDERS =
               {'Swf' : Swf, 'Swc' : Swc, 'FlashDir' : FlashDir,
                'FlashDevelop' : FlashDevelop,
                'FlashBuilder' : FlexBuilder, 'Air' : Air})


I'd dump the "Smart" builder, and make it a pseudo-builder.. (which is really what it is..)

Hope this helps!
-Bill