Add glim

[diegoferigo]

This PR adds https://github.com/koide3/glim, a versatile and extensible point cloud-based 3D localization and mapping framework.

---

Checklist

• Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
• License file is packaged (see here for an example).
• Source is from official source.
• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
• If static libraries are linked in, the license of the static library is packaged.
• Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
• Build number is 0.
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
• When in trouble, please check our knowledge base documentation before pinging a team.

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipes/gtsam-points/recipe.yaml, recipes/glim/recipe.yaml) and found some lint.

Here's what I've got...

For recipes/glim/recipe.yaml:

• ❌ The recipe must have a build/number section.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/25019821164. Examine the logs at this URL for more detail.}

[diegoferigo]

CPU and CUDA12 / CUDA13 builds work on Linux 🚀

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/glim/recipe.yaml) and found it was in an excellent condition.

[diegoferigo]

The glim recipe already looks quite good and it validates that the gtsam-points package from #33149 works as expected.

Currently glim vendors json nlhohmann, maybe it could be worth trying to unvendor it before marking this PR as ready for review.

[diegoferigo]

Unvendored nlhomann json and removed gtsam-points from this PR in favor of the new binaries from its new feedstock.

[diegoferigo]

@conda-forge/help-c-cpp, ready for review!

[diegoferigo]

I ran into a few issues after switching gtsam-points from the recipe in this PR to binaries from its feedstock. I needed several iterations on the feedstock to correctly fix the priority between the CPU and CUDA builds. However, as of today, the solver for glim still does not prefer the cpu binary with the highest build number, and instead installs a CUDA build of gtsam-points.

I suspect this should be resolved by marking builds 0, 1, and 2 as broken, but that is not a fast process. For now, I added a workaround in 93e163a that can likely be removed after the next release of gtsam-points.

[diegoferigo]

@conda-forge/help-c-cpp, ready for review!

[diegoferigo]

Tagging also @traversaro explicitly since the recipe structure is the same of #33149 that he reviewed recently.

[traversaro]

Why?

[diegoferigo]

I don't remember :) Maybe in early local attempts it was failing on linux-aarch64. I can remove it for now since CI is not testing this architecture. I can try again when I will enable it in the feedstock.

[traversaro]

I suspect this should be resolved by marking builds 0, 1, and 2 as broken, but that is not a fast process. For now, I added a workaround in 93e163a that can likely be removed after the next release of gtsam-points.

Can you explain more the relation of the cuda and cpu version of glim and gtsam-points? If the cuda version need each other, I think what you implemented is not a workaround, it is the correct solution (even if brittle as we use build string regex, at least until we have flags github.com/conda/ceps/pull/111).

For an example of this, see https://github.com/conda-forge/torchcodec-feedstock/blob/dcbb6b57b6b7f96786fee7a6f1be8a6d2ce70312/recipe/recipe.yaml#L109 .

[traversaro]

A few linux distros (mostly arch based) use glim as a package name for a different package, see https://repology.org/projects/?search=glim and https://github.com/junkdog/glim . Perhaps we can use a less ambiguous name? If we can't fine one, I think we can go for glim, at least the star count is in favour of https://github.com/koide3/glim .

[diegoferigo]

I suspect this should be resolved by marking builds 0, 1, and 2 as broken, but that is not a fast process. For now, I added a workaround in 93e163a that can likely be removed after the next release of gtsam-points.

Can you explain more the relation of the cuda and cpu version of glim and gtsam-points? If the cuda version need each other, I think what you implemented is not a workaround, it is the correct solution

It felt a bit hacky to me, mainly because I'm still getting familiar with best practices for CUDA builds. My expectation is that, after the recent changes in gtsam-points (especially explicitly adding the __cuda virtual package for CUDA builds), the correct variant should always be selected automatically. It's good to know that the solution I added is still considered appropriate. And yes, gtsam-points and glim do seem to be tightly coupled with respect to CPU/GPU compatibility.

A few linux distros (mostly arch based) use glim as a package name for a different package, see https://repology.org/projects/?search=glim and https://github.com/junkdog/glim . Perhaps we can use a less ambiguous name? If we can't fine one, I think we can go for glim, at least the star count is in favour of https://github.com/koide3/glim .

Given the popularity of the glim in this PR compared with the other project, and considering that we are not talking about debian-based distros (even if my roots are in arch linux xD), I would be ok proceeding with this name. That said, I do not have strong opinions on naming, so I am happy to consider alternatives.

[traversaro]

the correct variant should always be selected automatically

The problem is: how can the solver know what the "correct" variant is? If you just list gtsam-points as a dependency, you are telling the solver: any possible variant of gtsam-points can satisfy this dependency. If this is not true (for example, if only the cuda variant of gtsam-points is a suitable depenency for the cuda variant of glim) then we need some way to communicate that to the solver. If we do not do that, the solver has no way to know what the "correct" variant is.

[diegoferigo]

the correct variant should always be selected automatically

The problem is: how can the solver know what the "correct" variant is? If you just list gtsam-points as a dependency, you are telling the solver: any possible variant of gtsam-points can satisfy this dependency. If this is not true (for example, if only the cuda variant of gtsam-points is a suitable depenency for the cuda variant of glim) then we need some way to communicate that to the solver. If we do not do that, the solver has no way to know what the "correct" variant is.

My intuition is that it may still be possible to avoid relying on build strings here. I will try to explain my reasoning in case I am overlooking something.

The gtsam-points package already assigns different variant priorities to CPU and CUDA builds, with CUDA builds ranked higher. As a result, for a fixed version and build number, the solver should prefer cuda* over cpu*, even on CPU-only runners.

If the host provides __cuda, then either cuda12 or cuda13 is selected, and those are mutually exclusive because of cuda-version. With the __cuda run dependency I added here, those CUDA builds cannot be installed on CPU-only hosts.

Given that, my expectation is:

• on GPU hosts, the solver selects cuda* because it has higher priority
• on CPU-only hosts, the solver selects cpu* because it is the only installable variant

What am I missing?

[traversaro]

The problem is that in this case the fact that the "right" gtsam-points is installed is just a lucky combination, not something robust. In particular, what happens if it turns out that the CUDA build of the latest version has some critical bug and is marked as broken, while the CPU version is not marked as broken? In that case, the CPU version starts being installed by default. This is not something theoretical, it is literally what happened with jax/jaxlib in the past. In a nutshell, having an higher priority for cuda builds is just a nice convenience for users, not something you can rely on 100% of the time. If you want to be 100% sure that the right variant is installed, you need to let know to the solver which variant you need.

[diegoferigo]

what happens if it turns out that the CUDA build of the latest version has some critical bug and is marked as broken, while the CPU version is not marked as broken? In that case, the CPU version starts being installed by default.

In that case, while uncommon, I agree that the CPU version could end up being installed in CUDA environments. I would also expect that, in most situations, a new build would be published quickly. However, that would only address issues in the latest release, not in older ones.

That said, this concern applies mainly to recipes. In my environments (pixi.toml), I usually pin CUDA builds whenever I know I want them.

Thanks for the discussion. It helped me think more deeply about the overall system.