I actually do want to generate the SWF SWCs. My point was that during the SWF SWC build, there's no reason to build JS. For example, when building Basic.swc, it doesn't need to target JS. But while building BasicJS.swc, then obviously SWF and JS targets are needed. I'm not familiar with the IDE issues, though.
(BTW, on another machine using the SWCs in the final app, running a -debug=true compile for JS is much, much faster.) I'll try the anti-virus thing, thanks. -=-=- My original point of this thread was that I did set ROYALE_COMPILER_HOME (and other stuff) to a nightly build, and it didn't work. So I explained the exact steps that I used, and how I could modify the build.xml files to handle ROYALE_COMPILER_HOME correctly. So, there's probably more work to do (i.e. perhaps in prebuild, as Harbs pointed out), but the modified build.xml files will at least make it mostly work, by doing something that seems reasonable (actually reading the environment variable ROYALE_COMPILER_HOME). On 11/30/2020 1:44 AM, Alex Harui wrote: > 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" 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).
