Add CMake support; Resolves #565

[FunMiles]

The initial PR is way incomplete. It does work for MacOS :

• It does a proper and clean install of the library with the required public include files (including generated ones)
• It can be used a standalone or as a sub-project

However:

• No support yet for any other OS
• Not all tests and utilities are compiled

[bgoglin]

What do you mean "standalone" or "subproject"? It's cmake-specific ways to use it?

Do you need/want to make this for more than just MacOS X? Do you need/want more than just the library? I'd like to keep things simple and easy to test and maintain. Hence supporting less things would be nice. Building/running most tests under tests/hwloc shouldn't be too hard if only supporting Mac OS X. Running other tests may require to build tools, at least lstopo. Building lstopo requires some configuration/detection, for instance because of all lstopo backends (cairo, etc). Building lstopo in minimalistic mode (no cairo, no X11, etc) is easier (and will be enough for some tests).

[FunMiles]

What do you mean "standalone" or "subproject"? It's cmake-specific ways to use it?

Standalone vs subproject is a CMake specific issue. You can put the source of a library within your own project and then bring in the CMakeLists.txt of the subproject within your compilation. If you do this, you generally may not want that all the testing code be built, nor that the subproject library be installed. As the use via FetchContent mechanism does bring the library as a subproject, I wanted to make sure the build is clean for that case.
It is nowadays good CMake practice that any library project should be build in such a way that both form of use are cleanly supported.

Do you need/want to make this for more than just MacOS X? Do you need/want more than just the library? I'd like to keep things simple and easy to test and maintain. Hence supporting less things would be nice. Building/running most tests under tests/hwloc shouldn't be too hard if only supporting Mac OS X. Running other tests may require to build tools, at least lstopo. Building lstopo requires some configuration/detection, for instance because of all lstopo backends (cairo, etc). Building lstopo in minimalistic mode (no cairo, no X11, etc) is easier (and will be enough for some tests).

I would like to make this for MacOS, Linux and Windows at least.
It is probably best to limit the tests initially. I should be able to add Cairo/X11 detection fairly easily (at least for systems to which I have access) and supporting all the standard tools should be a goal.

[bgoglin]

Full Linux support would duplicate looooots of configure checks, and testing them will be very difficult because the target platforms are not in our CI and/or hardly accessible for us.

[FunMiles]

Full Linux support would duplicate looooots of configure checks, and testing them will be very difficult because the target platforms are not in our CI and/or hardly accessible for us.

I am sure you are correct. Let's start small, but at least support basic Linux configs? A lot of code in Linux uses CMake. I could put some warning output messages when running CMake for Linux users stating what is not yet supported/tested.

[jsquyres]

I am sure you are correct. Let's start small, but at least support basic Linux configs?

It's not really a question of only supporting a smaller set of features. Many of the configure tests are for portability between all the different distros / versions of Linux. E.g., the same feature XYZ may have differences between different distros and versions. Linux != Linux != Linux, unfortunately.

A lot of code in Linux uses CMake.

Just to be clear: all the code in Linux that uses CMake can still use hwloc as it is. The justifications for using CMake is not about making it available to users who currently cannot use hwloc because it is built with the Autotools.

[JackBoosY]

I think this file is not needed, right?

[FunMiles]

I am sure you are correct. Let's start small, but at least support basic Linux configs?

It's not really a question of only supporting a smaller set of features. Many of the configure tests are for portability between all the different distros / versions of Linux. E.g., the same feature XYZ may have differences between different distros and versions. Linux != Linux != Linux, unfortunately.

A lot of code in Linux uses CMake.

Just to be clear: all the code in Linux that uses CMake can still use hwloc as it is. The justifications for using CMake is not about making it available to users who currently cannot use hwloc because it is built with the Autotools.

I've been away for a long time, but is there an easy way to get a list for all the differences that impact hwloc?