Package Details: meshoptimizer 0.23-2

Git Clone URL: https://aur.archlinux.org/meshoptimizer.git (read-only, click to copy)
Package Base: meshoptimizer
Description: Mesh optimization library that makes meshes smaller and faster to render
Upstream URL: https://github.com/zeux/meshoptimizer
Licenses: MIT
Conflicts: gltfpack
Provides: gltfpack
Submitter: mosra
Maintainer: mosra
Last Packager: mosra
Votes: 5
Popularity: 0.63
First Submitted: 2020-04-18 11:43 (UTC)
Last Updated: 2025-03-20 11:40 (UTC)

Latest Comments

mosra commented on 2025-03-20 11:42 (UTC) (edited on 2025-03-20 11:42 (UTC) by mosra)

Thanks, that wiki is exactly what I was looking for.

Should be updated, I also removed the implicit strip to have a -debug package created with meaningful contents.

vitaliikuzhdin commented on 2025-03-20 11:17 (UTC)

@mosra, you are correct, with one minor exception: Release appends -O3 to the build flags instead of replacing them entirely. You can read more about both of these in the wiki.

mosra commented on 2025-03-20 11:08 (UTC)

Sure -- just to clarify, the None build type will make it use just the default flags supplied from makepkg.conf, right? I saw that in a few PKGBUILDs already, now I finally get why that's being done.

And for the RPATH, that's to undo what's being done at https://github.com/zeux/meshoptimizer/blob/f9cd9fdb053c2552a43b71f098962b649bcf3604/CMakeLists.txt#L121, right?

vitaliikuzhdin commented on 2025-03-20 10:45 (UTC) (edited on 2025-03-20 10:46 (UTC) by vitaliikuzhdin)

Would you mind considering a few more changes?

  1. Switch to the Unix Makefiles generator. The project is very small, so there is no need for a more advanced generator, which would introduce an additional dependency.

  2. Switch to -DCMAKE_BUILD_TYPE=None to prevent -O3 from being appended to the build flags.

  3. Add -DCMAKE_SKIP_RPATH=YES. Otherwise, gltfpack will have an RUNPATH of $ORIGIN/../.

mosra commented on 2025-01-12 15:36 (UTC)

Thanks for reminding me -- yes, I forgot, sorry.

I added gltfpack to provides and conflicts. This package is linked from the project README (https://github.com/zeux/meshoptimizer?tab=readme-ov-file#installing) which makes me think people shouldn't have a problem finding it.

vitaliikuzhdin commented on 2025-01-12 14:14 (UTC)

Sorry to bother you so often, but are there any updates on this?

vitaliikuzhdin commented on 2024-12-14 11:18 (UTC) (edited on 2024-12-14 11:23 (UTC) by vitaliikuzhdin)

If you decide not to split the build, that's totally fine. In that case, it might help to add conflicts=('gltfpack') so pacman doesn’t throw an error if someone tries to install both.

My main reason for suggesting the split wasn’t about saving disk space -- it was more about avoiding confusion. The full source build includes everything, but the binary version is named differently and only contains part of the project. Just a heads-up, provides and conflicts aren’t indexed by search, and you can’t use yay -Qo gltfpack for AUR packages since they don’t provide the content list. This is why I suggested the split -- without it, people might have trouble finding the right package. But it's up to you in the end.

mosra commented on 2024-12-11 08:01 (UTC)

Haha, originally this package didn't even contain gltfpack because I didn't have a need for it in magnum-plugins, but later on I thought "ah why not, it's small enough" and added it.

I'm not completely opposing your idea but it's more of a question of user convenience to me. For example libpng contains the pnm2png etc. executables and I don't think anybody really uses those. The main use case is supplying a library to be used by other packages, and the executables are there just because they're small enough and don't add any extra dependency. (As opposed to e.g. Debian-based distros, where each library is unnecessarily split into a billion of tiny & cryptically named packages, and the overhead of dealing with that outweighs any benefits of slightly less disk space used if only a subset is installed.)

And I see it similarly here, (to me at least) gltfpack is just one executable of the meshoptimizer library and since it's a single tiny file that has no other dependency that the library itself, it feels like unnecessary overhead to split it to a dedicated package that the user then has to explicitly install. If it'd be a multi-megabyte executable depending on various image libraries etc. (or if it'd be one of the GUI demos that use GLFW), splitting would make sense to me, but as it is now it doesn't really.

That being said, I can understand people who want to use gltfpack would search for that name and not for meshoptimizer. Would this be improved if I added provides=('gltfpack') to the PKGBUILD?

vitaliikuzhdin commented on 2024-12-10 15:30 (UTC)

Could you consider splitting this package into meshoptimizer and gltfpack? These tools are not necessarily used together, and maintaining a combined package creates confusion, especially since there is only a binary distribution available for gltfpack.

To resolve this, I've uploaded a gltfpack-bin package to the AUR, which provides the prebuilt binary. It would make more sense to have separate source-built packages for meshoptimizer and gltfpack rather than a combined one alongside a binary package that only provides gltfpack.

For an example of a possible split, you can refer to this gist: https://gist.github.com/vitaliikuzhdin/52c9b36124ee97e223dff8ae6ab5e206

This would make usage and maintenance clearer for everyone. Thank you!