[emscripten] additionaly build modularized version

[ololoken]

Emscripten build will produce additional package where generated JavaScript is wrapped into a factory function. It's useful for ondemand wasm module instantiation.

[oleg-derevenetz]

Hi @ololoken If you want to do this to improve the functionality of your launcher, there is no need at all to touch the project sources or file a PR. Just use this:

LDFLAGS="-sMODULARIZE -sEXPORTED_RUNTIME_METHODS=FS,ENV,noExitRuntime,addOnExit,run,callMain -sEXPORT_NAME=fheroes2" emmake make -f Makefile.emscripten

This works just fine (just tried with my changes from #9417).

Because today your launcher needs one set of exported symbols, and you file this PR. Tomorrow your (or some other's) launcher will need another set of exported symbols, and you (or the author of that other launcher) will file another PR. Instead of all this nonsense, I suggest just to use the standard GNU Make mechanisms that allow you to specify the additional build parameters for your own use from the outside without having to touch the source code.

[ololoken]

@oleg-derevenetz yes, but the plan is to download wasm module artifact into launcher on build

[oleg-derevenetz]

yes, but the plan is to download wasm module artifact into launcher on build

Well, as someone said, "imagine that this is done more than once". Imagine that some other guy decides to write some other 3-rd party launcher and he/she will need some different set of build options... Should we bundle another one variant to our build artifact?

[ololoken]

Not a problem, lets use EXPORT_ALL once and forever :/

[oleg-derevenetz]

Not a problem, lets use EXPORT_ALL once and forever :/

Please don't do this. There is no need to put some ad-hoc build parameters or build variants, that are intended just for your own 3-rd party launcher, into the main repo. Why don't you just want to build fheroes2 directly in your launcher's repo with the parameters you need, as I showed above? It can even be automated in future by monitoring the creation of new fheroes2 releases.

[ololoken]

ok, got your point

[ololoken]

BTW, let's consider if the project needs an official launcher?

[oleg-derevenetz]

BTW, let's consider if the project needs an official launcher?

As far as I understand, you decided to make your own launcher, which will be located outside of this project and you want to develop it yourself, as you please, right?

[ololoken]

I told it is temporary solution. It's not maintainable, created just to check if wasm build works.
Right now to run fheroes2.wasm you need:

1. serve generated files using http server
2. mount and populate virtual FS with original game data files

There is option to generate single html file. In that case *.js, *.wasm and *.data will be embedded as base64 encoded strings into large html. Theoretically, this file can be downloaded and opened in any browser locally.

But I decided to develop standalone launcher as it's easier to maintain something implemented as standard web application.

[oleg-derevenetz]

But I decided to develop standalone launcher as it's easier to maintain something implemented as standard web application.

Sure. But please understand that constantly introducing changes in the master branch via pull requests for each brand new idea related to the launcher development doesn't look good. It's even elementary slow process. Instead of doing this, I suggest either to build the WASM with your settings in your launcher's repo in the manner shown above, where you can quickly make and test the changes you need at the moment, or, if you prefer, you can make the necessary changes in some branch of your own fheroes2 fork, and then, when launcher will be more or less usable and ready for release, offer the single "final" pull request. Constantly changing compilation flags back and forth through pull requests is slow and inefficient.