incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Smith <>
Subject Re: Falcon location
Date Wed, 15 Aug 2012 05:57:43 GMT
The thread was continued as "Rearrangement of ... Flex". Did you read that one too? In any
case, I think the discussion can continue and perhaps you will persuade people. But my initial
post explained why I don't think it belongs in 'modules', and no one else has wanted it there.

 - Gordon

Sent from my iPad

On Aug 14, 2012, at 10:52 PM, "Om" <> wrote:

> On Tue, Aug 14, 2012 at 10:44 PM, Gordon Smith <> 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" <> wrote:
>>> On Tue, Aug 14, 2012 at 3:58 PM, Gordon Smith <> 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

View raw message