Hi, don't know if I understand right since all the things about the compiler are beyond my scope, but what I'm suggesting is to realocate resources. But don't know if this sounds crazy or not. In this way we can support current outputs (JS and SWF) but prepare for future outputs (WEBASM, iOS, Android,...)
so it will end as is: target | ------ assets (inside this folder all output like css, svg, png,...) | ------- swf (in this folder the .swf (s) app + modules, but for this all should search for resources in "../assets" for all assets not @Embeded in swf | ------- js (in this folder will go html and all js files that again should look for resources in "../assets" | -------- webasm | -------- iOS | -------- Android | -------- whatever other output we want to implement if not I understand that each output should provide its own assets folder, and this will end wasting resources for duplication (n times depending on how many outputs we want to get) and wasting time and CPU process.. does this make sense? 2018-02-27 18:11 GMT+01:00 Alex Harui <[email protected]>: > Hi Jason, > > Actually, I didn't know that. I'm not a compiler guy. Someone else wrote > the key pieces. I could see that way back, a compiler might have written > out intermediate information for the next step, like having a separate > linker that links the object files. But I don't think I've seen (or maybe > I just haven't used) options to output extra information for > post-processing after the final output. We could certainly output extra > information, but then that information needs to be parsed again to be used > by the publisher. > > If that's the way folks want to go, all we need is a volunteer to make it > happen. Currently, the publisher does not need the AST so it might even > be possible to write the publisher in ActionScript. But that might make > it harder to integrate with Maven. > > What do others think? > -Alex > > On 2/27/18, 8:54 AM, "Jason Guild" <[email protected]> wrote: > > >Alex: > > > >As you probably know, compilers in the old days were implemented in a > >series of stages as separate processes due to memory size limitations. > >The output from the previous stage was fed to the next stage as > >compilation proceeded until object files were produced. > > > >Maybe it makes sense for the compiler to output everything the publisher > >needs (final ASTs and/or other metadata, etc) when it exits. > >Then a separate publisher process could optionally use that output to do > >all the expected publish-type things without being intermingled with the > >compiler itself. > > > >The publisher would probably be simpler to understand on its own and > >maybe more people could be involved with it. > > > >Jason > > > >On 2/26/2018 8:49 PM, Alex Harui wrote: > >> The only > >> downside I've thought of is just that it is weird to have a publisher > >> attached to the compiler. I don't think most compilers have a > >>publisher. > > > >-- > >Jason Guild > >Analyst/Programmer V > >State of Alaska - Department of Transportation & Public Facilities > >Information Systems and Services Division > >820 E. 15th Ave. > >Anchorage, Alaska 99501 > > > > -- Carlos Rovira http://about.me/carlosrovira
