If this is the case it would be good if I could have something in the build to get the version of the framework and the version of the compiler. Also I would probably need some sort of information on which framework version the falcon compiler with completely different version numbers can build.
Chris -----Ursprüngliche Nachricht----- Von: Gordon Smith [mailto:gsmit...@hotmail.com] Gesendet: Freitag, 3. Oktober 2014 18:20 An: dev@flex.apache.org Betreff: Re: Is there a strict link between framework and compiler? Both the old compiler and Falcon autogenerate plenty of code (for data binding, child creation, etc.) involving specific classes and interfaces from the SDK. I don't known whether these classes and interfaces have actually changed across versions of the SDK, but it's possible that they have. So I think we should consider the compiler and the SDK to be paired. Eliminating this pairing by autogenerating data which gets interpreted at runtime might or might not be a good idea, depending on the performance implications. - Gordon > On Oct 3, 2014, at 8:08 AM, "Alex Harui" <aha...@adobe.com> wrote: > > > >> On 10/3/14, 2:39 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: >> >> If there is no strict link between compiler version an framework >> version ... would it actually be a good idea to have separate >> versioning for framework and compiler? > Falcon will probably have separate versioning. The first real release > will probably not be 4.x, but rather, 1.0. > > At one point, the goal was for Falcon to be more SDK-independent that > MXMLC. That was one of the reasons for compiler.mxml.children-as-data. > The less code generated by the compiler, the fewer SDK dependencies > there could be on that code. That was back when Falcon/ASC2.0 was to > be bundled in Flash Builder to be used for code intelligence. This is > less a concern for Apache Flex these days, so we don¹t have the same > motivation for Falcon to be SDK-independent, but IMO, since there are > fewer compiler-knowledgable people in the community, it still may be > worth finishing the children-as-data handling in Falcon and the SDK so > that future changes can be done in the SDK code. > > IIRC, there are subtle dependencies between MXMLC and the SDK it ships > with, but the short-term goal for Falcon is to get it to generate the > same code as MXMLC 4.6, and I don¹t believe Apache Flex has made any > other changes to MXMLC¹s generated code so I suspect that Falcon > should work with 4.6 and above. Then when that works, we can see > about getting compiler.mxml.children-as-data to have the same net effect. > > -Alex >
