I think those are all reasonable requests, thanks for opening those issues and highlighting them here! I hope we can make progress on each.
And hopefully other users can provide useful advice from their perspective and experience. About "no matching tags for llvm and bynarien, commit IDs quite hard to track (discussion in #9317/#9383)" - I think we have resolved that? Please let me know if not. And a general comment: Your overall experience does surprise me (which shows why it's good you wrote it up!) - that's a lot more local changes than I've seen elsewhere, and that includes some very large production user setups. So I hope we can work together to make your experience closer to theirs. * Are there tests in your codebase that we could run in upstream emscripten? * Do you test latest emscripten releases on your codebase as they are tagged? (Another option is to test the much more frequent tip-of-tree builds, but you may see more noise there.) * It would be good to discuss upstreaming long-term changes you mention like that EMT_STACK_MAX one - we may not be able to in all cases, but let's try at least (I don't think I remember a discussion on that one). - Alon On Fri, Sep 6, 2019 at 12:32 AM Beuc <[email protected]> wrote: > 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 > . > -- 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/CAEX4NpSma-S9LjCJ0Dbgsxxvd5N0Wkw5s1MO7Z6wxNHeux8Z2A%40mail.gmail.com.
