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 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
_______________________________________________
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
