flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Those @#*$^ Environment Variables
Date Sat, 14 Nov 2015 06:01:29 GMT

Folks are still getting tripped up trying to get prerequisite build tools
set up and ready to go.  Let’s use this thread to figure out a better
solution.  I know Chris is going to say “Maven” and I support that, but I
still think we can’t require everyone to go to Maven.

Some history:  There is a concept in the ASF of “build tools”.  Build
tools and operating systems and runtimes can have proprietary licenses.
Other kinds of dependencies must have Apache-compatible licenses or be
optional dependencies.  One test of whether some thing is a dependency or
a build tool is if code from that thing is used at run time or only during
the build.

So, for Apache Flex, the AIR SDK and Flash SDK (playerglobal.swc) are
considered build tools.  No code from airglobal.swc or playerglobal.swc is
linked into your SWFs and those files don’t get deployed and used by the
runtime at run time.

As I understand it, that’s one reason our build scripts don’t bring down
and install the Adobe SDKs and standalone debugger.  I think the consensus
was that source package should keep that distinction clear.

On the other hand, the Apache Flex SDK Installer does install the Adobe
SDKs, but it is dealing with the binary convenience packages which aren’t
official ASF releases.

In addition, I personally like the fact that the Adobe code can live
outside the source package and/or repo folders.  That way I know I won’t
accidentally commit any of it to the repos.  But it does mean that the
repos aren’t set up to be IDE-compatible, which has also been a pain point
for some folks.  However, I think we will have to find some other solution
other than copying files into the repo.  While the Flex SDK has both a
compiler and AS framework in one repo, FalconJX is a separate repo from
the FlexJS AS framework (which I think is a good thing) and that sort of
means you’ll never get a FlexJS repo setup with both a compiler and AS
framework in it.

Anyway, back to environment variables.  I believe one of the requirements
is to allow folks to choose different versions of the Adobe SDKs.  But do
we need to allow tons of flexibility on where those Adobe files go?  Do we
need to allow folks to keep more than one version around on their systems?
  Here are some ideas:

1) require that folks create an adobe folder in c:\ or HOMEPATH on Windows
and HOME on Mac
2) further require that the folder structure in the adobe folder is
something like air/versionnumber and flash/versionnumber (e.g. air/4.0.
The standalone debugger would go in flash/versionnumber as well.
3) #2 allows folks to keep more than one version of an SDK on their
machine.  But that pretty much means that you have to pass the version
number you want to use to the build scripts.  If we only required an air
and flash without version numbers, the scripts wouldn’t need to figure out
what version to use.
4) create scripts that take a version number and create and populate the
adobe folder.  I still would not fold these into the main build.xml.
These scripts will have to ask folks to accept the Adobe licenses before
5) create something the Apache Flex Installer can install that populates
the adobe folder
6) try to get our build scripts to find the air and flash SDKs from an
installed Flex or FlexJS SDK.  The problem with that is the standalone
debugger isn’t part of the install.

In sum, if we can assume that the Adobe stuff is going to be in a few
known places, we can hopefully eliminate most or all of the pain around
this sort of thing and eliminate the requirement for environment variables.


View raw message