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.
