Package Details: binaryen 64-1

Git Clone URL: (read-only)
Package Base: binaryen
Description: Compiler infrastructure and toolchain library for WebAssembly, in C++
Upstream URL:
Keywords: binaryen clang emscripten wasm webassembly
Licenses: MIT
Submitter: dariost
Maintainer: dariost
Last Packager: dariost
Votes: 10
Popularity: 0.224825
First Submitted: 2016-12-26 22:21
Last Updated: 2019-01-22 21:48

Latest Comments

Svenstaro commented on 2017-12-28 22:51

No, I agree. Let's keep it like it is. However, concerning your question, you'd do that using the epoch variable in the package.

dariost commented on 2017-12-28 18:31

@Svenstaro ops, sorry, I was in a rush and I didn't read the e-mail, I just updated it.

As I pointed out in a previous comment, I don't see any difference between the two versioning schemes aside from the fact that one gets updated every time there's an update in emscripten and the other one is indipendent from emscripten. As far as both versioning schemes get new releases I don't think it makes much of a difference, but if you think there is some good reason to follow the emscripten versioning let me know. Also, I'm not sure how to change the pkgver, because 40 is greater then 1.X.Y, so if you have any suggestion for handling that they're welcome.

Svenstaro commented on 2017-12-28 18:00

As a note to the maintainer: I think it might be useful to follow the emscripten-version-like releases and this is why I flagged this again but according to the discussion below you decided to go with the version_XX versions only. I'm not sure it matters. Either way, if you decide against this, just unflag.

applebloom commented on 2017-09-08 15:34

They have a weird tagging/versioning scheme.

dariost commented on 2017-09-06 22:12

Thanks for the patch @applebloom, now the package builds again with GCC.

About the versioning: I'm following the `version_XX` releases (for no particular reason, but if you have a good reason to follow the `1.YY.ZZ` versions let me know).
Also, version `1.37.20` (which is the same commit as tag `version_35`) is older than the current `version_37` (which is the same commit as tag `1.37.21`).

applebloom commented on 2017-09-06 16:28

Thanks for the reply.
Clang doesn't actually need this, but GCC does (unless we disable -Werror or -Wextra or at least -Wimplicit-fallthrough).

I posted patches for the version you currently have and the latest version released on github here:

There's a new version BTW, 1.37.20. Updated PKGBUILD:

dariost commented on 2017-09-05 22:22

Because version_37 doesn't build, it gives an error because fallthrough
The only patch available that I found was , which is for clang.
If you have a patch that works with GCC you can send it here or at my email address, and I will remove the clang dependency.

applebloom commented on 2017-09-05 21:34

Why does this package force building with clang?