Could you show an example of how you'd package this code?
If targeting only Linux workloads, use something like checkinstall to generate all lib-xyz-dev flavours.
If targeting cross platform, settle on one of conan, vcpkg or cmake packages.
A "classic C library" cannot assume the existence of pkg-config (or checkinstall, or conan, or vcpkg, or cmake).
It can assume the existence of the preprocessor.
EDIT: Since you modified the comment, it can at very least assume the existence of a compiler, a linker and make.
The OP library has a design such that the only build system you need is the preprocessor. That is a perfectly valid design decision, especially since this is explicitly for lighter-weight uses where GLib would be excessive. If you don't like it, don't use it.
EDIT: Clang, for example, does not provide a `make` or guarantee a `make` exists. It will happily co-exist with BSD make on FreeBSD, or GNU make on macOS, or no make at all. I assume you concede on pkg-config, etc.
Another example of lack of understanding how C toolchains work.
Since the days C got outside Bell Labs, every single C compiler has provided those tools.
Ignoring 50 years of C practices in library distribution is exactly that, willful ignorance.
> Just copy paste the source code in your source tree
And/Or make a simple CMakeLists.txt like this:
cmake_minimum_required(VERSION 3.22.0)
project(mylib C)
file(GLOB_RECURSE MYLIB_SOURCES
${PROJECT_SOURCE_DIR}/src/*.c
)
file(GLOB_RECURSE MYLIB_HEADERS
${PROJECT_SOURCE_DIR}/include/*.h
)
add_library(${PROJECT_NAME} STATIC ${MYLIB_HEADERS} ${MYLIB_SOURCES})
target_include_directories(${PROJECT_NAME}
PRIVATE "${PROJECT_SOURCE_DIR}/include"
)Also, OP referred to 'package repos', which obviously aren't involved in your example.
Now, the library gives me a .h and a `#define XXX_IMPL`. So to avoid making the mistake of defining XXX_IMPL more than once, I'll have to make a .c myself for each file of the library, and then I still need to write the CMakeLists.txt/Makefile/whatever.
This is just wasting my time for no good reasons.
I linked the imgui repository because that's what they do, they give you the .c/.h and you decide how to build it. You just have to copy/paste, no time wasted.
Hmm, I guess I wouldn’t worry about that and I’d just define XXX_IMPL in one of the existing .c files that imports the library. If I make a mistake and define it in multiple .c files then I’ll get an easy-to-interpret compiler error and it will be easy to fix the mistake. I imagine that’s how the author envisions the library being used. But yeah, if you don’t want to do it that way for some reason, then there’s no particular advantage to this style. I’m not sure that I hate it any more than I hate every other hack for distributing C libraries in the absence of a proper module system.
(and while Dear ImGui is definitely manageable, you still need to decide what to include in your project, for instance: why add imgui_demo.cpp)