Dealing with libraries in buildr-as3

[devboy]

Buildr-as3 doesn't support all the different options to link a library yet. (See Simon's list: http://www.newtriks.com/?p=802)

What is supported now is the library-path option for swc-files or directories containing swc-files:

compile.with "/path/to/file.swc" or compile.with "/path/containing/swcs/"

Adding additional source-directories works like this:

compile.from "path/to/src"

I have feature requests from Eric-Paul(@epologee) and Rasheed(@squeedee) to support the external-library option to prevent library-swcs being compiled into the target.

Not much of a hassle, but I am just wondering about what would be the best way to provide this in the API and keeping it consistent with the buildr project.

For example: In a Java project, compile.with "something.jar" will never merge that jar into the target and is therefore the opposite of what buildr-as3 is doing.

So what would you think about having something like the following:

compile.with "my.swc" will use external-library-path

compile.include "my.swc" will use include-libraries

compile.library "my.swc" will use library-path

The naming is probably not optimal.

Another option would be doing it with the help of hashes and stick with one function named "with":

compile.with :external => "my.swc"

compile.with :include => "my.swc"

compile.with :library => "my.swc"

compile.with "my.swc" <- this could fallback to one we decide to be the default.

Let me know what you think of it!

A second  

[newtriks]

My initial thoughts would be to try and keep the naming if at all possible as close as possible to the mxml options.  As you know I am clueless withBuildr build files but the rake workflow is clear for me, so could the below code be fashioned in some way?

define "example-debug.swf" do |t|

  configure_mxmlc t

end

desc "Compile and run the debug swf"

compile :debug => "example-debug.swf"

def configure_mxmlc t

  t.using :mxmlc

  t.library_path << 'lib/robotlegs/robotlegs-framework-v1.4.0.swc'

  t.library_path << 'lib/robotlegs/robotlegs-utilities-Modular-v0.5.3.swc'

  t.library_path << 'lib/as3-signals-v0.8.swc'

  t.source_path  << "lib/robotlegs"

  t.source_path  << "lib/tdd"

  t.external-library-path << "libs/player/playerglobal.swc"

end

task :default => :debug

[Dominic Gräfen]

I have to say that i would prefer keeping the ".with" Syntax!
I think buildr's strength is that its dsl simplifies a lot of the compiler options to make it better readable for humans.
Of course we would need some proper documentation explaining this.

[Squee-D]

Agreed. What's the point of an implementation agnostic DSL that then
tries to look like the implementation? It's not even a good one. You
may know compc/mxmlc convnetions and expectations but I bet you
arrived there through a painful and circuitous route. Anyone new to
compiling a Flex project shouldn't have to learn that cruft, this is
the point of Buildr, the same goes for when it's used against Java
etc.

Its amazing to me, that there are so many ways to skin a cat, that,
underneath it all, is just a cat. Dependencies are a graph, include/
compile against are the typical edge types, and temporary or hard
storage of artifacts are the expected outcomes from compiling the
graph into nodes. Such a nuisance to learn gobs of configuration
concepts because the flex compiler devs or anyone else decided to do
it "yet another way".

On Aug 14, 11:53 pm, Dominic Gräfen <dominic.grae...@gmail.com> wrote:
> I have to say that i would prefer keeping the ".with" Syntax!
> I think buildr's strength is that its dsl simplifies a lot of the compiler
> options to make it better readable for humans.
> Of course we would need some proper documentation explaining this.
>

[Dominic Gräfen]

True, true and true!
I decided to go with the hash variant and will choose "library" as default as that is the default behaviour of most IDEs!

[Squee-D]

This is, to me, about all there is to compiler dependency options.
Everything else i think is orthogonal..

http://www.gliffy.com/pubdoc/2843384/L.png

Actually, even 'in repo' or 'in dir' is orthogonal.

And certainly, roles are orthogonal, eg, if the task is 'test' then
there might be a 'test role' such as test.depends and test.contains

I find it unfortunate that this isn't a part of the buildr dsl. I
wonder if they'll accept my argument that there should be a de-facto
language of depends/contains :D

[Squee-D]

Of course i'm not suggesting this dsl for Buildr-AS3, i think the
closest match to the Java implementation is the correct one 'by
connvetion'

[Simon Bailey]

Missed the replies on this thread but after reading I totally agree with what your saying. I would say I come from a background of using these params regularly so keeping the naming conventions (for the AS3 port) made sense, plus other tools that compile for the Flash Player seem to keep the mxmlc naming conventions. However, I do see for continuity across Buildr naming consistency makes complete sense, either way I am sure there will be devs compiling AS3/Flex projects using Buildr-AS3 who will still have to research what each option actually does, but as stated above that is down to developers deciding on naming conventions not in line with existing compilers out there. So long as its clear I think its cool.

--
Cheers,

Simon

[ http://newtriks.com ]

[devboy]

I believe Buildr doesn't have an "include" term/functionality as this might not be a very common thing todo for Java devs because merging jar's is not a straight-forward task.

So is everyone fine with this solution:

[devboy]

I finally got around to implement this.

It is in this feature branch: https://github.com/devboy/buildr_as3/tree/feature/as3_dependency_types

Here is the commit-diff: https://github.com/devboy/buildr_as3/commit/8f70d98a3bcf89a138a828caeda75d038bb0baa9

I tested it briefly, we really need to set up these rspec tests ;)

Could you give it a try and see if it works as you expect it to!

Code review and feedback is as always very welcome too!