3 ms·

https://github.com/ocornut/imgui https://github.com/ocornut/imgui > Just copy paste the source code in your source tree And/Or make a simple CMakeLists.txt li

by linkdd 4y ago

https://github.com/ocornut/imgui https://github.com/ocornut/imgui > 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" )

foldr 4y ago
That's not really any different from how this library works. CLib just chooses to avoid the necessity of adding additional makefile definitions at the cost of making the preprocessor fast-forward through a bit more text. As it's a small amount of text anyway, I doubt it makes much difference. (The implementation code only gets parsed once, even though it's scanned multiple times by the preprocessor.) It seems a bit unfair to assume that the author has an "unwillingness to learn how to work with compiler toolchains and package repos" just because they chose to make this tradeoff. Also, OP referred to 'package repos', which obviously aren't involved in your example.
- linkdd 4y ago
  If the library was instead giving me a .c and a .h, I would simply need to make that CMakeLists.txt, or a Makefile, or whatever build system I use. 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.
  - foldr 4y ago
    >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 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.
flohofwoe 4y ago
Using file globbing isn't exactly 'best practice' for CMakeLists.txt files though ;) (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)

by linkdd 4y ago

foldr 4y ago

That's not really any different from how this library works. CLib just chooses to avoid the necessity of adding additional makefile definitions at the cost of making the preprocessor fast-forward through a bit more text. As it's a small amount of text anyway, I doubt it makes much difference. (The implementation code only gets parsed once, even though it's scanned multiple times by the preprocessor.) It seems a bit unfair to assume that the author has an "unwillingness to learn how to work with compiler toolchains and package repos" just because they chose to make this tradeoff. Also, OP referred to 'package repos', which obviously aren't involved in your example.

linkdd 4y ago
If the library was instead giving me a .c and a .h, I would simply need to make that CMakeLists.txt, or a Makefile, or whatever build system I use. 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.
- foldr 4y ago
  >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 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.

flohofwoe 4y ago

Using file globbing isn't exactly 'best practice' for CMakeLists.txt files though ;) (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)