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 05:51:20 GMT
On Tue, Aug 14, 2012 at 10:44 PM, Gordon Smith <gosmith@adobe.com> wrote:

> A large majority of people replying to this thread favor SDK, Falcon, TLF,
> BlazeDS, etc. being quasi-independent sub projects within the overall Flex
> project, so that's what Carol is planning for.
>
>
I think we should discuss this further at the end of which a vote should be
taken.  I don't think we are done discussing this yet to make this change.

I dint see a strong reason for Falcon to be a top level project anywhere in
this thread.

Thanks,
Om


> Sent from my iPad
>
> On Aug 14, 2012, at 10:23 PM, "Om" <bigosmallm@gmail.com> wrote:
>
> > On Tue, Aug 14, 2012 at 3:58 PM, Gordon Smith <gosmith@adobe.com> wrote:
> >
> >>> Falcon is a new version of the Actionscript compiler.
> >>
> >> Falcon is a reimplementation of mxmlc and compc. The AS support is very
> >> good. (It will ship as FB 4.7.) The MXML support is incomplete but
> Falcon
> >> can compile the framework test file Checkinapp.mxml.
> >>
> >>> Does it support mxml as well?  Or would that be a separate top level
> >> project?
> >>
> >> See above.
> >>
> >>> What do we call the compiler that is currently inside trunk?
> >>
> >> I call it "the legacy compiler".
> >>
> >>> If falcon gets a new top level project, shouldnt the current compiler
> >> get its own top level project?
> >>
> >> I don't have an opinion on that. I hope the old compiler dies as soon as
> >> possible.
> >>
> >>> Does Falcon work with exisiting flex sdk?
> >>
> >> It 's intended to eventually, but it's not yet ready to compile and run
> >> all SDK SWCs and tests yet.
> >>
> >>> If I create new components inside incubator/flex/SDK/trunk/, should I
> >> worry about who Falcon will work with it?  How would I set up my
> project in
> >> that case?
> >>
> >> Unless you want to contribute to Falcon, you shouldn't worry about it.
> At
> >> some point, if it becomes a suitable replacement for the legacy
> compiler,
> >> we will switch over and everything should just work the same.
> >>
> >>> Should I have copies of my new components in both
> >> incubator/flex/SDK/trunk/ and incubator/flex/Falcon/trunk/ to run both
> >> Mustella tests and Falcon's tests?
> >>
> >> No; incubator/flex/Falcon/trunk will be only for Falcon's Java code. No
> >> framework components will live there.
> >>
> >>> Does Falcon share any code with Falcon JS?
> >>
> >> Yes, it shares a front end (lexer/parser/symbol table). FalconJS and
> >> Falcon have different back ends (code generators). FalconJS is not ready
> >> for donation.
> >>
> >>> If yes, how might we want to change the repo structure if/when FalconJS
> >> is contributed to Apache Flex?
> >>
> >> We can figure that out when FalconJS is ready, but I think making it a
> >> sibling of Falcon would be best. It could share Falcon's front end just
> by
> >> putting Falcon's JAR on its classpath.
> >>
> >> - Gordon
> >>
> >>
> > Thanks Gordon!
> >
> > From what I read, it looks like Falcon is a new feature that will be
> added
> > to Apache Flex.   I believe it should be under
> /flex/trunk/modules/falcon.
> > And since it might be highly unstable, we should probably create a
> 'falcon'
> > branch to do this in.  Especially since you want to replace
> > /flex/trunk/modules/asc and /flex/trunk/modules/compile with the falcon
> > compiler.
> >
> > I think this structure follows what we have been discussing in the
> > branching strategy threads.
> >
> > Elsewhere, you said:
> >
> > 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."?
> >>
> >
> > Keeping it under /flex/trunk/modules/falcon would solve this problem too,
> > right?
> >
> > Eventually we should throwaway the /flex/trunk/modules/asc/ (legacy
> > compiler) and rename falcon to asc as well.
> >
> > 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.
> >
> > Thanks,
> > Om
>

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