Hi,

We almost never could use Emscripten without applying a few patches.
It's become increasingly difficult, not only to patch, but to convince the 
developers that it's legitimate, so I thought I'd detail our use case for good 
here.

So we've been using Emscripten with patches in emscripten, llvm and SDL2 port 
[1].
By the time a patch is officially included in a release, we usually need more 
patches as we face new issues -- or regressions.
Rinse and repeat.

Consequently for our production use (the RenPyWeb build that we publish to our 
users), we build an identified, versioned release (e.g. 1.38.42) with specific 
fixes.


New difficulties:
- scarse documentation for recompiling "upstream" (patch in progress #9383)
- no matching tags for llvm and bynarien, commit IDs quite hard to track 
(discussion in #9317/#9383)
- misleading versioning in tagged commits (#9282)
- grab-from-git port system; EMCC_LOCAL_PORTS considered for "local debugging", 
not cached, and causing issues (e.g. #9342 #9402)


Rebutals:

- "99% users use emsdk binaries"
Well, the remaining 1% will provide 99% of external contributions, take care of 
them :)
Also being able to test fixes before they finish the full review&ci process 
allows spotting issues in advance.

- "users will either use the unmodified binaries, or work on master/tip-of-tree"
No, we use an identified, tagged Emscripten version, because it's more stable 
than a random commit.
Also when we publish a hot fix, sometimes a couple months after release, we 
need to reproduce the same build environment

- "emsdk can build from source"
This build process doesn't allow patching, so it's only when one doesn't trust 
the binaries and wants to rebuild them as-is AFAIU.
(To be honest, I'd like to be able to use the binaries, but Emscripten being 
bleeding-edge, I figure that'll have to wait :))


I hope this makes clear why we need to checkout emscripten/llvm/bynarien for an 
existing release, patch it, and build it.
Preferably without reverse-engineering the build process and fighting all the 
stack.
That's the first time I have to justify this while working on free/open source 
software.

How do you people deal with this?


[1] For instance, our current release needs these patches, some of them still 
needing work & official integration:

- https://github.com/emscripten-core/emscripten/issues/9257
Work-around ./configure misdetection

- https://github.com/emscripten-core/emscripten/issues/9097
Fix fullscreen exit causing wrong screen size

- hard-coded change to EMT_STACK_MAX which isn't configurable

- https://github.com/emscripten-core/emscripten-fastcomp/pull/195
Compiler limitation when combining several Emscripten features

- https://github.com/emscripten-ports/SDL2/issues/88
Send SDL_APP_TERMINATING on page exit

- https://github.com/emscripten-ports/SDL2/issues/70
Support Emterpreter/Asincify in SDL2

- Search "Emscripten" in https://renpy.beuc.net/#status_reports for all the 
other patches that were eventually integrated over the year

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/20190906073253.yh5wv677v3l4xn4k%40mail.beuc.net.

Reply via email to