Skip to main content
Participant
May 1, 2013
Answered

AIR SDK 3.7 include-sources repeatable are broken

  • May 1, 2013
  • 1 reply
  • 962 views

Hi.

I've recently tried to upgrade the SDK I'm using (3.3) to latest version. The upgrade resulted in failed builds. Upon firther investigation it turned out that only one class was compiled into SWC, not all.

We use ANT to compile SWC files like this:

<compc output="${project.name}.swc">

                              <source-path path-element="${src.dir}" />

  <include-sources dir="${gamedata.dir}" includes="**/*.as" append="true" />

                              <include-sources dir="${src.dir}" includes="**/*.as" excludes="some/package/*.as" append="true" />

</compc>

Internaly this results in a command like this:

compc -output=xxx.swc -include-sources+=a/b/A.as -include-sources+=a/b/B.as -include-sources+=a/b/C.as

The resulting xxx.swc only con-tains a.b.C class

Some extra testing showd that the folowing syntax work correcty:

compc -output=xxx.swc -include-sources+=a/b/A.as,a/b/B.as,a/b/C.as

Digging through the bytecode, I found the probable cause of this error.

In compile.jar, com.adobe.flash.compiler.config.Configuration method setIncludeSources is called for every "-include-sources" instance on command line. This method in turn calls fillListWithResolvedPaths, that does a target.clear() on every call. This would explain why only the last passed value in command line is actualy processed.

I tried this also with SDK 3.5 (but did not bother with others) so I assume this bug was introduced with ASC 2.0.

Also I see that "include-stylesheet uses the same internal method, so it should be simillary affected.

I'd realy like to use the new SDK, because of one specific feature (stack traces in release code, swf 18, http://www.adobe.com/devnet/articles/flashplayer-air-feature-list.html). Switching the old SDK with the new produced failed builds.

This topic has been closed for replies.
Correct answer chris.campbell

Thank you for the report.  I've talked with the compiler team and they have confirmed that this is a bug.  Would you mind opening a public bug report on this over at bugbase.adobe.com and let me know the bug number?  I associate your public bug with our internal report so you can track its progress.

Thanks,

Chris

1 reply

chris.campbell
chris.campbellCorrect answer
Legend
May 1, 2013

Thank you for the report.  I've talked with the compiler team and they have confirmed that this is a bug.  Would you mind opening a public bug report on this over at bugbase.adobe.com and let me know the bug number?  I associate your public bug with our internal report so you can track its progress.

Thanks,

Chris

Zobo__Author
Participant
May 1, 2013

Hi Chris!

Thanks for getting back to me so fast. Here is the requested report: https://bugbase.adobe.com/index.cfm?event=bug&id=3552881

I was also wondering, is this part of the code closed now? Befoe there was a public SVN withe the compiler, debugger client etc.

Best,

Damjan

Zobo__Author
Participant
May 6, 2013

One possible workaround. If the source specified in '-include-sources' can be on the source-path, you could use '-includes' instead of '-include-sources'.

As for the question of getting the new compiler source... it is not public, but Falcon (original codename for the new compiler) was forked and contributed to Apache Flex. This Java code was refactored to match Apache Flex package names. It has since diverged from ASC 2, but a lot of the code is very similar.


Hi Chris.

I tried to understand '-includes', but I somehow couldn't get it to work on a set of files.

Anyway, I saw that there was some movement on the bug report I opened, but nothing concrete. I hope this will be treated as a bug that breaks old behaviour nad as it seems trivial from my point of view (I don't know your internal procedures) and will be fixed before the next release of SDK.

Thanks again. I will mark your first answer as correct.

Best.