On Wed, Jul 9, 2014 at 4:32 AM, Alon Zakai <[email protected]> wrote:
> As mentioned this is being done with upstream. > > But the question here is whether we should import a copy SDL2 into our > repo, or use a separate repo, where people would need to download it > separately. I don't think the separate repo can be SDL upstream since we > might need some fix before it gets reviewed and merged there, so we do need > a fork. So the question is, should our fork be in the main emscripten repo, > or in another. > > There has been discussion in the past about a "package manager" or > "package repo" system, specifically empkg by LCID Fire. That approach > didn't get much interest at the time from the community (and I admit to > have been too busy back then to get into it), and seems to have been taken > down meanwhile. But perhaps this is a good time to revisit it. > > In summary, here are some options here: > > 1. Merge SDL2 into our main repo. People just grab emscripten, and can > then build with -lSDL2 and it works. This is what we do with libc, > libc++abi, libc++ (and some JS-implemented libraries like SDL1.3, glew, > glut, etc.). This seems easiest for everyone. > libc, libc++abi and libc++ are critical the functioning of emscripten. SDL2 isn't. Any version here will eventually diverge from the upstream. SDL isn't part of the "emscripten product" and there's no harm to having people pull it separately. If there are difficulties in that area, they should get resolved by improving the toolchain. If people *really* want it packaged together, that sounds like something that could be done as part of emsdk and some new buildbot tasks to ensure that things are kept functioning. As for the JS-implemented libraries ... I think that the library_gc.js should probably die in favor of people just getting and using Boehm and SDL 1.3 should be removed. While those were fine for a research project, I don't think they rise to the quality, performance or usefulness to be part of the "emscripten product" or platform. 2. Keep our SDL2 fork in a separate repo by itself. People need to grab it > manually and link with it. > Nothing wrong with a separate repo as long as it is intended to only have differences from upstream on a short term basis. > 3. Keep our SDL2 fork in a separate repo of ported projects, that has some > system for making it convenient to use. That is, there is an easy way to > get and build and integrate with emcc any of the projects there. > This sounds good too. - Bruce -- 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]. For more options, visit https://groups.google.com/d/optout.
