Immediate-Mode-UI
pls add cmake support
There was an effort a while ago to encompass everything with cmake https://github.com/Immediate-Mode-UI/Nuklear/pull/462
While I think that may be a bit overkill for our situation, it could give you something to try out.
I also maintained some cmake definition files a while ago. You could add a Nuklear definition to it: https://github.com/robloach/cmakepacks
I don't think this repo need to add cmake, because in the example folder already have a makefile and it since quite great.
While 462 does everything, perhaps a simpler approach may be one that...
- Doesn't handle building the demos
- Exposes the target and the include directory
- Keeps it to only one CMakeLists.txt file
While 462 does everything, perhaps a simpler approach may be one that...
.... Add #753 as optional dependency then because FreeType is already set up for cmake
+1, would make it easier to integrate into existing projects just making a target and exporting include path would be enough
+1, would make it easier to integrate into existing projects just making a target and exporting include path would be enough
Your making it sound like it's a chore to add a single-header file to a project, which is not true
+1, would make it easier to integrate into existing projects just making a target and exporting include path would be enough
Your making it sound like it's a chore to add a single-header file to a project, which is not true
Keeping side project files in your repo, even if it's a single header, is generally not a good idea.
Yes, I can use cmake's FetchContent, setup paths and make target, but won't it be nicer just to write one line FetchContent_MakeAvaliable?
Keeping side project files in your repo, even if it's a single header, is generally not a good idea.
Then why is it so common to find a folder usually called "3rd party" or etc that contains such files? Even things like giant SDK's do this.
Yes, I can use cmake's FetchContent, setup paths and make target, but won't it be nicer just to write one line
FetchContent_MakeAvaliable?
It would be, assuming that there's no obnoxious configuration that needs to be done.
Anyway, if someone stumbles upon this, here is my solution that can be adjusted for your own needs:
include(FetchContent)
FetchContent_Declare(
nuklear_src
GIT_REPOSITORY https://github.com/Immediate-Mode-UI/Nuklear.git
GIT_TAG 4.12.3
GIT_SHALLOW TRUE
GIT_PROGRESS TRUE
)
FetchContent_MakeAvailable(nuklear_src)
FetchContent_GetProperties(nuklear_src)
set(NUKLEAR_PREFIX_INCLUDE ${nuklear_src_SOURCE_DIR}/include/)
file(MAKE_DIRECTORY ${NUKLEAR_PREFIX_INCLUDE})
file(COPY_FILE
${nuklear_src_SOURCE_DIR}/nuklear.h
${NUKLEAR_PREFIX_INCLUDE}/nuklear.h)
file(COPY_FILE
${nuklear_src_SOURCE_DIR}/demo/sdl_opengl3/nuklear_sdl_gl3.h
${NUKLEAR_PREFIX_INCLUDE}/nuklear_sdl_gl3.h)
# here would be fixes for switching to SDL3
add_library(nuklear INTERFACE)
target_include_directories(nuklear INTERFACE ${NUKLEAR_PREFIX_INCLUDE})
add_library(nuklear::nk ALIAS nuklear)
I have a Nuklear C++ wrapper library project (https://github.com/Xeverous/nukleus) and I can tell that if Nuklear maintainers don't want it it's probably because it is an extra burden that requires CMake knowledge and additional maintenance. I somewhat disagree with this decision too but I will honor it.
I'm currently writing CMake for my library and @trexxet I think your approach is flawed because Nuklear is not technically a header-only library. It just has a source - it's just embedded into its header. In practice this means that CMake should define it as STATIC, not INTERFACE, provide both header and source files and also expose any macros one might want to define for the project as target_compile_definitions(nuklear PUBLIC ...) so that descendant projects inherit the configuration.
