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. 2. Keep our SDL2 fork in a separate repo by itself. People need to grab it manually and link with it. 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. - Alon On Mon, Jul 7, 2014 at 10:52 PM, Bruce Mitchener <[email protected]> wrote: > On Tue, Jul 8, 2014 at 12:49 PM, Mark Callow <[email protected]> > wrote: > >> On 08/07/2014 04:04, Sathyanarayanan Gunasekaran wrote: >> >> I think SDL2 is used enough that emscripten benefits from integrating >> the cross compiled SDL2 into master, but this could to increase in >> size(the cross compiled bitcode is 1.4M). Do we want to integrate this >> into emscripten? Thoughts? >> >> >> I think SDL2 should be integrated to master. The currently included SDL >> version is not useful for porting as there is no native version. >> >> I am still trying to get the test version to work in my project. I was >> off for a couple of days but am about to resume the effort. >> > > Maybe I'm nuts, but why effectively create a fork of SDL2? Why not have > this merge upstream? > > A build bot could still be set up to build and pull SDL2 and run tests > using the current / incoming / whatever version of emscripten. > > - 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. > -- 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.
