Add support for cmake

[innerout]

I have been using uthash lately in several projects that all use CMake. The project's header-only nature is easy to use and integrate, but problems arise when installing the projects depending on uthash in a system. I want to ask if I could work on a PR that would add basic support for CMake for the project and incrementally make it complementary or replace completely Makefiles existing in some directories.

[Quuxplusone]

The only Makefiles that exist in the repo today are in tests/ and doc/, neither of which is relevant to your interests.
If you're having trouble integrating uthash in a CMake project and you think you know a patch that would improve that story, then sure, pull requests welcome. But I would be surprised by that. Usually it's trivially easy to integrate a single-header library into a project under any build system.

[innerout]

Sorry If I did not explain it clearly the integration is indeed trivial the installation is nonintuitive. Anyway I will provide a patch in the next days and open a PR. Thanks for the fast response.

[wdhongtw]

CMake may be too huge for this beautiful project itself.
But it's a good try for build automation in C/C++ ecosystem. :D

---

Probably uthash project can describe itself with minimal CMake manifest file.

cmake_minimum_required(VERSION 3.11)
project(uthash VERSION 0.1.0 LANGUAGES C)

add_library(uthash INTERFACE)
target_include_directories(uthash INTERFACE src)

If so, consumer project of this library can use it by following snippet.

include(FetchContent)
FetchContent_Declare(
  uthash
  GIT_REPOSITORY https://github.com/troydhanson/uthash
  GIT_TAG        <some tag/branch/commit-hash>
)
FetchContent_MakeAvailable(uthash)

Once this snippet is added, there is no need for manually copying the headers. :D

There are some benefits for direct and indirect consumer of uthash by adopting this.

First, when updating uthash library, we only need to update the GIT_TAG anchor,
rather than replace entire file of local copy. This experience is similar to git sub-modules.

Second, by the mechanism of CMake, there will only be one copy of uthash even if
multiple targets in our working set depend on uthash

A -> uthash
A -> B
B -> uthash

If A and B both using CMake (and depend uthash as described above), only one copy of
uthash source is clone in the build process.

---

I have a fork of uthash and a simple repo to demonstrate the client side usage.
If the above scenario looks good, maybe I can submit a PR for this. :D

• wdhongtw/uthash at adopt-cmake
• wdhongtw/usage-uthash

[wdhongtw]

Some additional considerations:

Whether to introduce another folder layer, e.g. require user to #include "uthash/uthash.h", may need careful decision.
If we want to be consistent with system packages in common Linux distribution, the extra layer seems not prefered,
so just providing src as target include folder works in this case.

• uthash-devel-2.3.0-7.fc40 - Fedora Packages
• Debian -- package files: uthash-dev/bookworm/amd64
• Arch Linux - uthash 2.3.0-2 (any)

@wdhongtw

[innerout]

Although I originally opened this issue, I agree with @Quuxplusone, CMake is not needed for uthash, it is header only, and it is trivial to use in any project either as a dependency in the build system, or through a system package. If you are a CMake user you can use it like this link(search uthash in the file) and it is really close to the solution you provided @wdhongtw. You can even just download the file and store it in your project, this solves all the build system issues (given that the code is updated infrequently).