For vendored hwloc, allow to build the minimal version

[nazar-pc]

The way configuration of hwloc works by default is that it looks at some of the system libraries (that is my assumption anyway) and based on what it find, requires extra dependencies.

For example in some cases it needs cudart and in others it doesn't.

My use case is to only know CPU topology and to be able to pin threads to a set of CPU cores, so all of the extra stuff just makes it harder to build.

At the same time configuration of hwloc has some options to disable CUDA and other things, which I think might have been helpful to expose. For example build minimal version by default and require vendored-full or something for default build with complete feature-set (just because features in Cargo are additive).

WDYT?

[HadrienG2]

I'm wondering how acceptable it would be to say that vendored builds only cover the minimal hwloc feature set, and those who want more should roll their own hwloc builds.

[nazar-pc]

For me that'd work, but since the difference is just CLI options for configuration it doesn't look like a lot of burden to support two configs: minimal and default, comparing to just one of them.

[HadrienG2]

What makes me uneasy here is that vendored-full would not mean "build hwloc with all features enabled", as one would expect, rather it would mean "build with every feature that the hwloc configure script has detected support for on the host system". Which can go wrong in two different ways:

• The configure script may detects some library on the host, that cannot actually be used without extra setup from the user's side, resulting in a seemingly unrelated build failure later on. This most commonly happens with CUDA.
• The user intended to build hwloc with support for feature X, but X was not detected on the host system due to some PATH configuration error, and thus hwloc ended up silently being built without it.

The way one normally handles these issues in an autotools workflow is to run ./configure interactively, carefully check the output for any unexpected configuration choice, and only run make once the configure script output fully matches expectations. However vendored builds break this workflow by hiding the configure logs so well that only relatively advanced cargo users even know there are ways to get to them.

From this perspective, I would say that vendored builds are fine for simple use cases like "my linux distro has outdated hwloc packages and I want to probe the hardware topology and pin some threads", but any use of hwloc more complex than this would probably be better served by the extra control and much greater ease of debugging that an interactive hwloc build provides.

[nazar-pc]

If the concern is naming, it could be called vendored-default or something. I don't have strong preference about it either way, just thinking about some use cases that (assuming host is configured properly) could be made to work, but would now require messing with manual compilation of hwloc.