Targeting Specific SDKs

[Joel Hooks]

Is it possible to target specific SDKs? Specifically I want to target
the Flex 4.0 trunk.

[Luke Bayes]

Hey Joel,

That's another great question - in the spirit of publishing this week
- I just threw together a detailed response here:

http://www.asserttrue.com/articles/2009/11/23/can-i-target-a-specific-sdk-using-project-sprouts


Thanks!

Luke

[Joel Hooks]

I read through that Luke, and I still don't really get how I can target specific sdks (unless they exist as remote gems?). I already have the SDK on my harddrive, why do I need to snag it again?

Also, say I want to use the most current FlexUnit4 and generate my test templates based off that instead of ASUnit3 (4 is very exciting!).

While I like the concept, it seems like sprouts is very prescriptive (reminds me of flex-mojos a bit in this regard). Am I making it more complicated than it really is?

[Luke Bayes]

Hey Joel,

Thanks for the clarification on the SDK part of the question.

This is a feature that has been requested by more than a few folks.

I've dug into the sources a few times with the intent of supporting
this and just haven't gotten all the way there yet.

Admittedly, I keep getting hung up on what it means to clobber the
package management features that RubyGems provides.

For me personally, I feel like disk space and bandwidth are cheap
enough that it doesn't bother me to have 4 or 5 sdks in my Sprout
cache, especially considering they're each one-off downloads that get
reused by different projects.

Assuming we decide to accept environmental variables (like FLEX_HOME
for example), we introduce some awkward synchronization problems when
working on a team or deploying to a CI server. All of a sudden, we can
have different developers compiling with different SDKs and getting
different results (which has happened quite a lot to Ali and me in
Flex Builder). Maybe environmental variables aren't the only way to
solve this problem, but checking system-specific paths into the
rakefile feels like a non-starter to me. Are there other ideas for
supporting this use case?

We've considered checking the SDK into our project/vendor path, but
that has it's own host of problems - especially related to versioning
the multi-hundred-megabyte SDK...

With that said, I'm finding myself in the minority with these concerns
and because of that, have an interest in supporting it...

Anyone want to fork and contribute on this feature?

;-)

Whatever we do, I'd like to make it work across 'Tool' entities rather
than just for the Flex SDK alone.



As far as using a different test framework, you're absolutely correct
that Sprouts is opinionated about this particular question!

For whatever it's worth, Robert Penner is actively working to build a
new release of AsUnit that will feel a lot more like FlexUnit 4 (but
better) and integrate nicely with Flex/Flash Builder. While we eagerly
await that release, there are some things you can do to get
unblocked...

Just to preface what is about to sound pretty complicated, we're
running with the idea that common tasks should be dead simple and
difficult tasks should be possible.

In working with FlexUnit, you'll lose at least the 'unit' test helper
build task and need to describe this functionality manually (i.e.
without the ProjectModel) using the base mxmlc and flashplayer Rake
tasks.

You should remove the following line from the default rakefile:

unit :test

and replace it with something like the following:

mxmlc 'bin/SomeProjectRunner.swf' do |t|
t.input = 'src/SomeProjectRunner.as'
t.default_size = '800 600'
t.default_background_color = '#ffffff'
t.source_path << 'lib/flexunit4'
t.source_path << 'lib/yourotherlib'
t.library_path << 'lib/yourotherlib.swc'
end

flashplayer :test do |t|
t.swf = 'bin/SomeProjectRunner.swf'
end

Of course, you'll need to pull down the latest FlexUnit and put it
into your lib.

If you want to customize the generators, it's definitely possible, but
a little bit more complicated.

You'll want to create a new folder in your project root named,
'vendor/generators' and within that folder, copy the folders that you
can find in our git repo at: 'bundles/as3/lib/sprout/generators', or
'bundles/mxml/lib/sprout/generators'.

Whenever you run script/generate, it'll check for this folder first
and pull any named folders based on the name you specify (defaults to
'class') to script/generate.

The only real problem here, is that thanks to how I've integrated with
Rubigen, each file template is duplicated in the different generators.
So, if you sometimes just want to run script/generate suite, you'll
need to edit the TestSuite.as template in the suite generator, the
class generator and the test generator...

I personally think that's poop, but it's what we've got today. Ideally
- generators would be able to trigger other generators, I suspect
that's possible, but haven't yet looked into how to do this.

There's a more detailed description of how we work with Generators
halfway down the page here:

http://projectsprouts.org/rdoc

You can also add custom generators / bundles to your home path if you
want Sprouts to pick up project generators.

Of course, if you were to create a custom bundle with different
generators, I'd love it if you pushed it out as a Gem to
sprout-yourname-bundle so that others could take advantage of it too!

Check out our 'mxml' bundle for an example of a simple bundle - heck -
If you get in there, please fork and send me a pull request!

I'm more than happy to add a FlexUnit bundle that would work like mxml
and/or as3 bundles, it's just not something I've needed, so I haven't
done it.


Please let us know as you hit other questions.


Thanks!

Luke

[Joel Hooks]

On Nov 23, 2009, at 3:48 PM, Luke Bayes wrote:

> Assuming we decide to accept environmental variables (like FLEX_HOME
> for example), we introduce some awkward synchronization problems when
> working on a team or deploying to a CI server.

interestingly, it appears to be using my FLEX_HOME envar.

> I feel like disk space and bandwidth are cheap
> enough that it doesn't bother me to have 4 or 5 sdks in my Sprout
> cache,

I don't disagree with you. I'm just a control freak. This is why I'm not a Rails guy. Magic makes me sad, and removing that level of control (which specific SDK to use) is frustrating. What if I need to monkey patch?

That said, I am really keen on making Sprouts work for me. :>

[Luke Bayes]

On Mon, Nov 23, 2009 at 2:24 PM, Joel Hooks <joel...@gmail.com> wrote:
> On Nov 23, 2009, at 3:48 PM, Luke Bayes wrote:
>
>> Assuming we decide to accept environmental variables (like FLEX_HOME
>> for example), we introduce some awkward synchronization problems when
>> working on a team or deploying to a CI server.
>
> interestingly, it appears to be using my FLEX_HOME envar.

Hmm. I suppose it's possible got further along than I meant to on some
late night of hacking! I'll be sure to look into that.

>> I feel like disk space and bandwidth are cheap
>> enough that it doesn't bother me to have 4 or 5 sdks in my Sprout
>> cache,
>
> I don't disagree with you. I'm just a control freak. This is why I'm not a Rails guy. Magic makes me sad, and removing that level of control (which specific SDK to use) is frustrating. What if I need to monkey patch?

Monkey patching is another thing - if you're just looking to hack on
your system, you can always symlink the folder where Sprouts looks for
the SDK to wherever you want...

~/Library/Sprouts/0.7/cache/sprout-flex4sdk-tool/archive

Sprouts should be able to support whatever level of control you're
looking for - you'll just become more exposed to detail as you get in
there. Speaking of monkey-patching, one of the great (and horrible)
things about Ruby, is that you can duck-punch
(http://www.ericdelabar.com/2008/05/metaprogramming-javascript.html)
it into whatever shape you want as you find issues and things you want
fixed...

> That said, I am really keen on making Sprouts work for me. :>

Woot!

lb.