I may not fully understand the goals. I think it is:
1) download the compiler instead of building it so you don't need a JDK
2) Only build the JS SWCs because you don't need the SWF SWCs.
For 1), I think you can grab a nightly build or binary release and point
ROYALE_COMPILER_HOME and ROYALE_TYPEDEFS_HOME into the subfolders of that build
so the scripts will copy the appropriate files into your royale-asjs working
copy. I haven't tried, but hopefully it will work or only require a few tweaks
to get to work.
IIRC, the reason the compiler is copied into royale-asjs is so that the
directory can be a legitimate SDK for some Royale/Flex IDEs. I think it also
allows some scripts to work better as well.
For 2), if you don't have AIR_HOME and PLAYERGLOBAL_HOME and
FLASHPLAYER_DEBUGGER defined in the environment, then the build should skip
building the SWF SWCs. Pretty sure that's how the js-only builds are created.
IIRC, the reason there are both SWF swcs and JS swcs is because, if you want to
have your app target both SWF and JS, the external definitions need to be more
SWF oriented and the JS code "just works" because it doesn't have strict
runtime type checking. But if you only want to target JS, you can have a
different set of external definitions.
Could the build only compile the JS output once? Yes, but currently there are
separate projects for SWF and JS to make some IDEs happy (FlashBuilder, for
example) and each project need to run independently and probably shouldn't bet
on the other project having built the JS output. If Royale abandons
FlashBuilder and other legacy IDEs (probably a good idea in 2021), then the
royale-asjs build can be refactored.
Also, on Windows, I have found that disabling virus scanning on file writing
(in the royale-asjs folders and subfolders) can speed up the build.
HTH,
-Alex
On 11/29/20, 5:09 PM, "Edward Stangler" <estang...@bradmark.com> wrote:
I can understand generating the SWF target for the xJS.swc (JS) build.
The SWF targets are fairly quick.
I'm mostly hoping there's a way to avoid building the JS target for the
x.swc (SWF) build. The JS targets take much, much longer for my
machine, at least*. So eliminating half of those would speed up my
build tremendously.
* = Machine is definitely IOPS-bound, but perhaps just general slowness.
On 11/29/2020 3:18 AM, Harbs wrote:
> I remember having this discussion before and the reason was nuanced
enough that I don’t remember. The SWCs are not the same, but I don’t remember
exactly the difference.
>
> JS SWCs always require a SWF target because that generates the actual SWC
which the JS files are then added to. It would be great to be able to avoid
that piece, but that’s not something that we’ve done yet.
>
>> On Nov 29, 2020, at 10:58 AM, Edward Stangler wrote:
>>
>> BTW, why are both SWF and JS targets being built for both x.swc and
>> xJS.swc? Seems like double the compile time (both x and xJS get built
>> at the same time, anyway).
