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.
Sent from my iPad On Aug 14, 2012, at 10:23 PM, "Om" <bigosma...@gmail.com> wrote: > On Tue, Aug 14, 2012 at 3:58 PM, Gordon Smith <gosm...@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
