You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Christofer Dutz <ch...@c-ware.de> on 2014/10/03 11:39:14 UTC
Is there a strict link between framework and compiler?
Hi Guys,
after finally managing to strip Flexmojos from any direct reference to any compiler artifacts (You now explicitly have to specify the compiler you want to use and there's no default anymore). Now I'm working on making it possible to build Flex applications with Falcon. One thing that I noticed is that there allways was the requirement to use the compiler-version matching the framework version. Is this actually still valid? Shouldn't it be possible to compile Flex applications for Flex 4.13 with the compiler of 4.8 or even Adobe Flex? I bet you should only need this dependency on the same version if the framework utilizes new language featrues that the new framework uses.
I'm asking this, because with falcon I have no idea which framework versions I would be able to use.
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?
For now I'll simply disable the version-equality check in Flexmojos.
Chris
AW: Is there a strict link between framework and compiler?
Posted by Christofer Dutz <ch...@c-ware.de>.
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:gsmithsf@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" <ah...@adobe.com> wrote:
>
>
>
>> On 10/3/14, 2:39 AM, "Christofer Dutz" <ch...@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
>
Re: Is there a strict link between framework and compiler?
Posted by Gordon Smith <gs...@hotmail.com>.
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" <ah...@adobe.com> wrote:
>
>
>
>> On 10/3/14, 2:39 AM, "Christofer Dutz" <ch...@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
>
Re: Is there a strict link between framework and compiler?
Posted by Alex Harui <ah...@adobe.com>.
On 10/3/14, 2:39 AM, "Christofer Dutz" <ch...@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