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? >> > >> > >> >> Cheers! >> >> Sylvain >> >> >> >> -- >> >> 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/396623d9-674b-88ce-1c78-62b43b7b1090%40beuc.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/421d3f5d-0b5b-dcc2-4e29-03e4fe9c7dd4%40gmail.com. > > -- > 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/CAEX4NpQi9AxwcOYaH_VND%2B9rF%3Dnkx1w2K%3DN60UQ3zSmcyS__PA%40mail.gmail.com. -- 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/CAL_va28ik-mb7pop9PyU_O-P3SZ6rK%3DCB2kkCSO7ZgivoiLM8g%40mail.gmail.com.
