Open
Conversation
The lime module source is now located in src/lime instead of in the root directory.
Update the backend package path found in the source tags that get used in modular build mode.
The haxelib classpaths added to the hxml string in ModuleHelper.hx did not take any custom classpaths defined in a library's haxelib.json file into account. This change relies on the new getPathClassPath function added to my fork of the hxp library. It can be found in the classpath-change branch.
Haxe 4 removed the XMLSocket class from the js package, so it will only be included in modular builds if the app is being built with Haxe 3.
Html5 dependencies will still be embedded like before on non-modular builds.
--no-inline is now deprecated, so it will only be used if someone is building with Haxe 3.
Three layers of nesting is too many, adding confusion for minimal benefit. Additionally, there's no need to calculate and pass `$globals`, when Haxe already runs the exact same calculation.
This mode failed because we weren't passing `$hx_exports` into `script()`. In this mode, Lime's core classes are stored in `$hx_exports.lime`, so we need access. The reason we didn't pass `$hx_exports` is because `System` writes to `$hx_exports.lime.embed`. We do want to get access to that function, but don't want it to be overwritten. Therefore, we passed in an empty object, and read `lime.embed` from that object. The most straightforward solution is to store the two different functions in two different places. That way, there's no risk of one overwriting the other. Nor can the function accidentally call itself, so we don't have to check for that either.
This must have been missed in bc3a5f7.
Didn't mean to commit these, whoops!
The flag is `lime_modular` now, so this would only have run if `modular` was defined for some other reason. If it did run, the only difference would have been that it wouldn't quite allocate enough space.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
As discovered by @Digivorix, building with
-D lime-modularis currently broken, and likely has been for 7+ years. This mode outputs separate .js files for Haxe, Lime, and OpenFL, among others, with the idea that most of them can be reused. Each file would add their classes to$hx_exports, then the final app could reference those exported classes.The core of the problem is that, instead of passing
$hx_exportsto the app, we created an empty object and passed that instead. Without access to basic OpenFL, Lime, or Haxe classes, the app couldn't run.As far as I can tell, the only reason not to pass
$hx_exportsis becauseSystemwill overwrite$hx_exports.lime.embed. We want to expose output.js's wrapper function in that spot, and the wrapper needs to call the functionSystemexports. Solution: haveSystemexport to$hx_exports.lime.system.System.embedinstead.Downside: if the wrapper never runs, then the page can't call
lime.embed, which it might expect to be able to do. But that would require runninghaxe Export/html5/haxe/release.hxmlmanually to remove the wrapper, which also strips away the embedded libraries, so I don't think that's ever been a supported use case.Note: this PR is not enough to run OpenFL apps in modular mode. OpenFL will need a patch of its own.
Note 2: this includes #2013, because I considered a solution that would have required it.