flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: AW: [FALCONJX] Combining SWF and JS compilers (was Re: AW: [FalconJX][FlexJS] COMPJSC and Build order)
Date Tue, 31 Jan 2017 17:41:53 GMT
OK, I have something working.  It is in the "dual" branch I just pushed.

I added a -compiler.targets option.  It allows you to specify a list of
targets.  I am deprecating -js-output-type.  It should still work for now,
but it only specified a single output for JS compilation.  With
-compiler.targets, the currently known set of allowed values is:


I've added a JSFlexCordova but haven't implemented it yet.  And I haven't
implemented extensibility for this list.

I've added a new 'client' for each new output type.  The old MXMLC still
generates the SWF.  MXMLJSC is now a shell that calls MXMLC, or one of the
new clients like MXMLJSCFlex and/or MXMLJSCNode and/or MXMLJSCNative.
These clients create the appropriate backend and publisher and do their
work and report back errors.  The MXMLJSC shell collects all errors and
reports them.  Depending on how you set -compiler.targets, you can specify
SWF compile before FlexJS compile or vice-versa or skip SWF compilation
completely and generate JS only from Flash Builder.

But there is a catch:  MXMLJSC requires Java 7 or greater and Flash
Builder is packaged with Java 6.  So, in order to use this capability from
FB, you will need to upgrade FB to use Java 7 as in this post [1].  So
that's the first question:  Would we want to require folks to upgrade FB
to Java 7?  I don't think we can script the upgrade to automate it for
people as there are permissions issues in the process.  But currently, I
think it is worth it, since that means you don't have to use separate
launch scripts to run the JS compile, although I think it is possible to
have a way to fall back to the current mechanism of SWF-only compilation
and use the separate launch script if folks can't upgrade.

Using -compiler.targets, I was able to go back to using the Basic.swc and
on the JS compile it told me where I was still using Flash APIs.  This was
a main motivator for combining the compilers.  Currently the code in
HTML.swc wraps Sprites for the SWF code which I think is now unnecessary.
So that's question #2:  Can I start replacing HTML with Basic?

Right now in the Nightly builds, the workflow is to compile your app
against the same set of SWCs for both SWF and JS.  Each SWC is packed with
the JS files.  But the JS compile is referencing classes in
playerglobal.swc.  With these changes, I added new options like
-js-external-library-path and -js-library-path and -js-define so you can
specify a different set of SWCs for the JS compile.  I think that's better
because then you don't have Flash-only classes in the JS compile.  But it
means that a library is no longer one SWC.  We'd need to distribute both
Core.swc and CoreJS.swc and so forth.  Same for third-parties.  So that's
question #3:  Any objections to moving from one SWC per library to two?
IMO it is worth it as it is cleaner:  You are compiling each SWC against
the true API set for that platform.

The -js-define allows you to specify different conditional compile flags
for JS vs SWF, but I copied the approach Fred took a while back and
allowed using -define=COMPILE::SWF,AUTO and -define=COMPILE::JS,AUTO and
the compiler clients will set the appropriate defaults.  So question #4:
Any objections to supporting "AUTO" as a special value?



On 1/13/17, 9:33 AM, "Alex Harui" <aharui@adobe.com> wrote:

>Back to working on this again...
>Currently, there are "clients" like MXMLJSC, COMPJSC, and ASDOCJSC.  You
>launch one of these clients.  Then you specify (via -js-output-type) what
>"backend" you want the client to use.  A backend supplies an "emitter"
>that walks the AST and generates some sort of output.   These "backends"
>also currently supply a "publisher" that packages up the output.
>I think going forward, there may be a need to have different publishers
>for the same backend/emitter.  For example, it might turn out to be
>beneficial to specify a Cordova publisher that knows how to place the
>output and add Cordova plugins to a Cordova project structure.  Right now
>we have an Ant script and it doesn't have an extensible way of adding
>Cordova plugins.  A Cordova-specific publisher could examine the JS output
>and detect directives to add certain plugins to the Cordova project.
>That could be a significant time-saver for folks building Cordova apps
>with FlexJS.
>Then there is the main goal of this thread which is to allow the developer
>(especially the developer using an IDE) to launch a single client and run
>both a SWF compile and a JS compile.  SWF compilation is currently done
>with a different set of clients (MXMLC and COMPC).
>If I understand Chris's suggestion below, it might be better to have a new
>client for each backend.  So, instead of MXMLJSC with js-output-type=NODE
>and MXMLJSC with js-output-type=FLEXJS, we'd have MXMLNODEJSC and
>MXMLFLEXJSC clients and no -js-output-type parameter.
>Now having an additional switch for the publisher makes this a bit more
>complex.  We might then have an MXMLFLEXJSCCORDOVA as well that knows how
>to output to Cordova projects.  What do folks think of this idea?
>The backend would no longer be responsible for a publisher.  They would be
>separate entities integrated by a client.
>Then for Flash Builder, the flex-compiler-oem jar would simply launch more
>than one of these clients and aggregate the output.

View raw message