Yeah that is what I was walking about. I know there are some conflicts in
AS vrs JS and they are warnings.
My point is, the exceptions in the compiler are what you should be worrying
about right now. Those are secondary to the actual transpiler logic of the
semantics of as to js.
Mike
On Fri, Mar 18, 2016 at 3:25 PM, Christofer Dutz <christofer.d...@c-ware.de>
wrote:
> Well this is the output:
>
>
> Mrz 18, 2016 8:01:12 PM com.google.javascript.jscomp.LoggerErrorManager
> println
> SCHWERWIEGEND: [missing]:101: ERROR - Parse error. identifier is a
> reserved word
> function int() {}
> ^
>
> Mrz 18, 2016 8:01:12 PM com.google.javascript.jscomp.LoggerErrorManager
> println
> SCHWERWIEGEND: [missing]:107: ERROR - Parse error. identifier is a
> reserved word
> int.prototype.toString = function(opt_radix) {}
> ^
>
> Mrz 18, 2016 8:01:12 PM com.google.javascript.jscomp.LoggerErrorManager
> println
> SCHWERWIEGEND: [missing]:226: ERROR - Parse error. identifier is a
> reserved word
> int.MAX_VALUE = 2147483648;
> ^
>
> Mrz 18, 2016 8:01:12 PM com.google.javascript.jscomp.LoggerErrorManager
> println
> SCHWERWIEGEND: [missing]:233: ERROR - Parse error. identifier is a
> reserved word
> int.MIN_VALUE = -2147483648;
> ^
>
> Mrz 18, 2016 8:01:12 PM com.google.javascript.jscomp.LoggerErrorManager
> printSummary
> WARNUNG: 4 error(s), 17 warning(s)
>
> Guess this shouldn't happen.
>
> Chris
>
> ________________________________________
> Von: Michael Schmalle <teotigraphix...@gmail.com>
> Gesendet: Freitag, 18. März 2016 20:20
> An: dev@flex.apache.org
> Betreff: Re: [FALCONJX] Some help with the externs
>
> > Another thing I noticed, was that I was getting errors while generating
> the AS code for "js"
>
> Are you sure these aren't errors/warnings from the actual GCC compiler?
>
> Mike
>
> On Fri, Mar 18, 2016 at 3:15 PM, Christofer Dutz <
> christofer.d...@c-ware.de>
> wrote:
>
> > Hi Alex,
> >
> > Oh gee ... I should never have started migrating the externs ;-)
> >
> > I have invested about 3 full days now and have all projects creating the
> > identical AS output as the Ant build. Currently I'm working on the last
> > module "js". Unfortunately this seems to be the "playerglobal" of FlexJS
> > :-( ... one thing I noticed, was that the "externs/js/externs" directory
> > contains the content of the externs.zip which is embedded in google's
> > closure compiler. So far so good, but looking at the build, the zip is
> > extracted to the "externs/js/externs" directory, but strangely the files
> > are structured with a "browser" directory. The original zip however
> doesn't
> > contain any directories, so where does that directory structure come
> from?
> >
> > Another thing I noticed, was that I was getting errors while generating
> > the AS code for "js", now I compared that output with the one of the Ant
> > build and I am getting exactly the same errors. Why that? Errors
> shouldn't
> > be part of the build and they should break the build.
> >
> > But on the cool side, I have started building a first flex-maven-plugin.
> > As the Ant build uses manually created config files, I simply created
> > something that does it the same way. Now I sill have to think of a way
> how
> > to make the build reference the swcs in the maven-local repo as
> referencing
> > relative paths is really bad. But probably I'll stick to that first.
> >
> > Chris
> >
> > ________________________________________
> > Von: Alex Harui <aha...@adobe.com>
> > Gesendet: Freitag, 18. März 2016 16:22
> > An: dev@flex.apache.org
> > Betreff: Re: [FALCONJX] Some help with the externs
> >
> > On 3/18/16, 7:22 AM, "Christofer Dutz" <christofer.d...@c-ware.de>
> wrote:
> > >
> > >The problem I am having is that I completely don't understand how
> EXTERNC
> > >sometimes generates the AS immediately and for createjs it is invoked
> > >twice. The first time creating JS output, the second time creating AS
> > >output. This is really strange as I would like to Build all projects the
> > >same way or at least know why they are built differently and document
> > >this in the pom.
> > >
> >
> > Crap, forgot all about that "feature". The js-root option gets the
> > ExternC compiler to consume the JS implementation of a library where the
> > code has function bodies and doesn't have a clean mapping from its file
> > paths to package names and output the .js files that ExternC otherwise
> > expects. I supposed it could be another tool broken out from ExternC or
> > maybe we could make ExternC's normal code paths handle the situations the
> > js-root handles.
> >
> > HTH,
> > -Alex
> >
>
