Hi, In case you'd like to inspect some build recipes for inspiration :) https://github.com/renpy/renpyweb/blob/master/scripts/ffmpeg.sh (broke in the past) https://github.com/renpy/renpyweb/blob/master/scripts/libjpeg-turbo.sh (broke in the past) https://github.com/renpy/renpyweb/blob/master/scripts/fribidi.sh (simple autotools) https://github.com/renpy/renpyweb/blob/master/scripts/libpng.sh (less simple autotools) https://github.com/renpy/renpyweb/blob/master/scripts/libzip.sh (cmake) https://github.com/renpy/renpyweb/blob/master/scripts/SDL2_image.sh (cross-compile with webp support) https://github.com/renpy/renpyweb/tree/master/scripts (for more)
All are currently built static-only, remove --disable-shared for testing dynamic builds. Tarballs URLs are in https://github.com/renpy/renpyweb/blob/master/Makefile - Beuc On Fri, Oct 11, 2019 at 04:05:20PM -0700, Alon Zakai wrote: > Sounds good to me. > > Separate "contrib" directory sounds good too. We may want to move some > existing ports to there, like say cocos2d. > > On Fri, Oct 11, 2019 at 3:29 PM 'Sam Clegg' via emscripten-discuss < > [email protected]> wrote: > > > On Fri, Oct 11, 2019 at 2:28 PM Alon Zakai <[email protected]> wrote: > > > > > > Yeah, I think we can add repos to emscripten-ports for things like that. > > We don't need to add support in the emscripten repo itself for them, which > > does make it more like nacl-ports. So there would be two tiers in > > emscripten-ports support; they'd all be in emscripten-ports, but only some > > would have code in emscripten itself. > > > > > > Concretely here, we could add ffmpeg to emscripten-ports but not to > > emscripten, and add a test in emscripten, and then we'd get regression > > tests to avoid issues there, which given the history could be useful. The > > only objection I might have to that is if the test is very slow. Otherwise, > > if someone's interested to do it, it sounds good to me. > > > > > > > I broadly agree with the approach. One thing to note is that more > > ports should not need to be forked to exist in this system. It > > should be enough to commit a simple build recipe (e.g. emconfigure && > > emake) along with an upstream URL. The emscripten-ports > > organization is mostly used/useful for hosting forked repos. I think > > I'm suggesting something more like the "emscripten/tools/ports" tree, > > where each project is represented by some metadata and they all live > > in the same tree. > > > > For now I propose the following: > > 1. Add ffmpeg to "emscripten/tools/ports". Use emmake and emconfgiure > > here to mimic the build process used by upstream/Beuc. > > 2. Add an optional flag to mark ports as "contrib" or "second tier". > > This would signal that normal CI doesn't build them, and they don't > > get built by "embuilder build ALL" or get listed by default by > > "embuilder list". > > > > Perhaps we can use a subdirectory called "contrib" under > > "emscripten/tools/ports". Any ports in that tree would be less > > frequently tested and have a lower bar for entry. Then we can have > > people add whatever ports they want there. > > > > > > > > On Wed, Oct 9, 2019 at 10:59 PM Gabriel Cuvillier < > > [email protected]> wrote: > > >> > > >> Regarding the Emscripten "Ports", why not having something like NaCL > > >> "Web Ports" system ? > > >> > > >> https://chromium.googlesource.com/webports > > >> > > >> For example, the list of ports for Pepper 47 version: > > >> > > >> > > https://chromium.googlesource.com/webports/+/pepper_47/docs/port_list.md > > >> > > >> > > >> This is a 3rd party repository (that is, not in NaCL main tree) for > > >> projects buildable on the NaCl platform. It was a very handy by the > > time. > > >> > > >> I understand the reluctance to have every possible ports in the > > >> Emscripten tree (apart maybe some very common stuff, such as SDL2, zlib > > >> or Freetype), though having a "ports ecosystem" is nevertheless > > >> something needed > > >> > > >> > > >> Le 09/10/2019 à 22:18, 'Sam Clegg' via emscripten-discuss a écrit : > > >> > On Wed, Oct 9, 2019 at 3:05 AM Sylvain Beucler <[email protected]> wrote: > > >> >> Hi, > > >> >> > > >> >> On 08/10/2019 21:12, 'Sam Clegg' via emscripten-discuss wrote: > > >> >>> On Wed, Oct 2, 2019 at 12:35 PM Beuc <[email protected]> wrote: > > >> >>>> I just upgraded 1.38.45->1.38.46 and I got a new build failure in > > an unmodified ffmpeg build. > > >> >>>> Which is also what happened last time I upgraded Emscripten 1 > > month ago (different error). > > >> >>>> I don't see wasm-ld-related notes in the ChangeLog, but apparently > > it got stricter again. > > >> >>>> Compiling a few external libs may actually be a good release test > > case for the Emscripten project ¯\_(ツ)_/¯ > > >> >>>> > > >> >>> I think are you referring to this bug > > >> >>> https://github.com/emscripten-core/emscripten/issues/9565? > > >> >>> > > >> >>> The good news is that we now have a unit test to cover that specific > > >> >>> issue. But I agree we also need larger system tests. Perhaps we > > >> >>> could add ffmpeg to our build somehow, perhaps via an improved ports > > >> >>> system. > > >> >> This one, and #9566 (probably related to Python w/ sockets build). > > >> >> > > >> >> "perhaps via an improved ports system": I wouldn't recommend it, > > because > > >> >> IMHO the point of Emscripten is to build libraries as-is (through > > >> >> emconfigure/emmake), rather "port" them individually. For instance > > the > > >> >> SDL2 port is a bad use case for this test, since its build system is > > >> >> remade from scratch and Emscripten-specific. We want to test a > > >> >> vanilla/portable external build here. > > >> >> > > >> > Sorry, thats not what I meant. I just mean some kind of repository > > >> > of packages that are known to be buildable with emscripten. I didn't > > >> > mean we should do work on the upstream projects to port them. > > >> > > > >> > A bit of background: I've been pushing back on adding more ports > > >> > recently because I'm not sure we want to have every open source > > >> > package in the emscripten tree itself. So what I mean when I say > > >> > improved ports system is some way to list third party packages that > > >> > are buildable (along with the build recipe), that are not necessarily > > >> > part of the "core" emscripten but should certainly be tested with each > > >> > release. I don't know that best way to achieve this just yet. > > >> > Perhaps something in the emscripten tree? or perhaps an external repo > > >> > (like llvm's test suite: https://llvm.org/docs/TestSuiteGuide.html)? > > >> > Perhaps driven by embuilder? Perhaps not? -- 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/20191012082053.aywvh4hmihv7ydfs%40mail.beuc.net.
