Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SWC builds appear to add all files to 'definition stores', which includes (in some cases) files with no actual definitions. #116

Open
greg-dove opened this issue Feb 2, 2020 · 3 comments

Comments

@greg-dove
Copy link
Contributor

A good example of this seems to be the XML swc build for SWF.

It correctly generates an empty swc with no definitions other than an internal swf with the container 'XMLClasses' class which has no content and no dependencies.
But all files in the local project seem to be scanned, despite 'include-classes' only specifying XMLClasses as the root for determining dependencies.

While building the swf swc, it lists the following warning(s) for XMLList and also for XML:

Warning: The definition XMLList depended on by AS3.vec.Vector$object in the SWC C:\Users\Greg.m2\repository\com\adobe\air\framework\airglobal\20.0\airglobal-20.0.swc could not be found

What is happening here?
As best I can tell it is like this:
The local XML.as and XMLList.as files are added as DefinitionPromises in the SWF build, even though they are not actually supposed to be included.

These DefinitionPromises for XML.as and XMLList.as 'shadow' the original definitions from the airglobal (or playerglobal) swc.

The DefinitionPromises don't resolve to actual definitions, because (from a COMPILE::SWF perspective) the XML.as and XMLList.as files are 'empty'

AS3.vec.Vector$object has some dependency on the original definitions in the airglobal.swc and these definitions from elsewhere within the swc are now hidden by the invalid DefinitionPromises from the local files... hence the warning.

I was able to tweak some of the code in ASProjectScope to avoid this warning, but I was not at all confident that it is a correct 'solution'. Just noting that down here as the main location that seems important to work in for anyone else who might give attention to this. Otherwise it is probably not high priority, because it is a warning only.

@aharui
Copy link
Contributor

aharui commented Feb 2, 2020

I believe you are describing the source-path behavior?
https://lists.apache.org/thread.html/r4de920f5ce762460abe342ee0e3f8dbf694ed1c06c3d45de9ccf2997%40%3Cdev.royale.apache.org%3E

At the end of the thread, Josh explains why it is useful for IDEs

@greg-dove
Copy link
Contributor Author

@aharui
It is probably describing something similar, but this issue is additionally describing what I think is an invalid internal state for the compiler, that can result from that.
The outcome is nothing bad (beyond the strange warnings being displayed) in this case, so I don't think this is a priority. But something does not seem right to me here, and may not make sense longer term...

The warning is essentially saying that something in the airglobal.swc can't find one of its dependencies also defined in the same swc. The reason is because an 'empty' project-local file that was not intended to be and will never be included in the swf version of the XML swc build is hiding it.

The 'XML' lib classes only have a 'COMPILE::JS' definition and there is no definition for COMPILE::SWF content - because they are obviously already defined in the airglobal/playerglobal as native classes.
The behavior inside the compiler appears to create an invalid internal view of the loaded definitions for swf compilation of this lib, where the 'empty' local source files override/shadow the original native definitions with an invalid 'DefinitionPromise', which seems wrong IMO.... especially as they are both a) empty for swf and b) not specified as being included in the swc.

I'm not giving this more attention at the moment apart from seeking to understand it... and documenting that here. If you really feel like this is not an issue for some reason, feel free to close it with a quick explanation why.

@greg-dove
Copy link
Contributor Author

Another way to think of this is that it is creating a empty monkey-patch I guess.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants