incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Om <>
Subject Re: Falcon location
Date Wed, 15 Aug 2012 07:51:10 GMT
On Tue, Aug 14, 2012 at 11:11 PM, Alex Harui <> wrote:

> On 8/14/12 10:51 PM, "Om" <> wrote:
> > I dint see a strong reason for Falcon to be a top level project anywhere
> in
> > this thread.
> >
> I think we eventually want to break the compiler's ties to a specific
> version of the SDK.  That gives it a better chance to be incorporated into
> IDEs and used for other things like code models, and to be used as a front
> end to FalconJS.
MXML is a feature of the Flex SDK.  How can we ship Falcon without the Flex
SDK?  Who would be using it?

This is Gordon's original comment and I agree with it:

Like the old compiler, Falcon is tied closely to the Flex framework because
> of the semantics of MXML. Therefore, I think Falcon belongs initially
> "inside" Flex, like the old compiler was inside Flex. Eventually, it would
> be interesting to try break many of these dependencies and let Falcon
> become its own project independent of the framework, but I see that as
> longer-term evolution.

In the long term, it probably makes sense to move it a top level project,
but in the short term having it outside of the current flex sdk folder
structure will make it extremely difficult to work with.  No one has
answered Gordon's question:

If Flex has independent subprojects like SDK, Falcon, TLF, etc., how would
> we tie them all together to do testing? With environment variables that say
> "use this branch of the SDK, this branch of Falcon, this branch of TLF,
> etc."?

This sounds like a nightmare.  Scenarios like these are the reasons why
having feature branches makes sense.  Isnt this what we all discussed in
great detail in the "branching thread"?

Yet another issue I raised that has not been addressed:

As I see it, Falcon is a codename for a new version of the compiler.  We
> are mixing functional names like "asc" and "compiler" with codenames like
> "falcon".  What happens when we want to build a new version of actionscript
> compiler after falcon?  We dont want to have that existing alongside with
> another codename as well.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message