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? > >> > > >> > > >> >> 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 > . > -- 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/CAEX4NpSAHNqHQbJStth-ynca0TDyG2tJuF3v4hDewx52MTNpog%40mail.gmail.com.
