incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Om <bigosma...@gmail.com>
Subject Re: Falcon location
Date Wed, 15 Aug 2012 17:43:47 GMT
On Aug 15, 2012 9:07 AM, "Alex Harui" <aharui@adobe.com> wrote:
>
>
>
>
> On 8/15/12 12:51 AM, "Om" <bigosmallm@gmail.com> wrote:
>
> > On Tue, Aug 14, 2012 at 11:11 PM, Alex Harui <aharui@adobe.com> wrote:
> >
> >>
> >>
> >>
> >> On 8/14/12 10:51 PM, "Om" <bigosmallm@gmail.com> 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?
> It is the other way around.  We should have the flexibility to deliver
> Falcon separately from the SDK.  The commercial tool vendors shouldn't
have
> to re-integrate Falcon every time we cut a new release of the SDK.  That
is
> why they cannot leverage MXMLC in the IDEs other than strictly as the SWF
> compiler.
> >
>
I agree that it is the way to go in the long run.  But, from Gordon's
description, it does not sound like Falcon its anywhere close to achieving
this.  In the short term, making it a top level project creates a barrier
that  would prevent people contributing to it.  Which in turn would delay
the eventual goal of making a separate release of Falcon.

> >
> >
> > 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"?
> Features of a single deliverable like the SDK.  But I think Falcon should
be
> thought of as a separate sub-project.  TLF as well.  Both Falcon and TLF
can
> be involved in SWFs without any other SDK code in it.

Is there any reason why we can't do the same while having Falcon inside the
modules directory?  Once we achieve this goal, we can move it out to a
separate project.

> >
> > 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.
> >>
> I'm not understanding.  The proposed folder structure has "sub-project"
> names at the top.  I don't see folders called 'asc' or 'compiler'
> >

Gordon mentioned that Falcon replaces the ' legacy compiler'  which are the
projects asc and compiler.   This means that once Falcon proves itself, we
would make the switch and get rid of the legacy ones.

Retaining the name 'Falcon' at that point would only cause confusion.

In the end, here is what I am proposing:

Lets keep Falcon inside /flex/trunk/modules/falcon.  It would make working
with it much easier.  Work on making Falcon sdk-independent  can also
happen here.   Once that goal is achieved, we can move it to a too level
project-by which time it should just be a directory copy.

If we still want to make Falcon a top level project, I would like to see
how the the the typical developer set up would look like.   Just saying
consider it a top level project without figuring out the dev setup is not
very helpful in making such a decision.

Gordon asked the same question and has not been discussed in this thread.

> > Thanks,
> > Om

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