CMake #8566
Replies: 4 comments
-
|
One problem is almost always how/where to access third-party librairies required to link backends, in a way they doesn’t add constraints to the consumer. This code above doesn’t seem to begin to consider this? The first thing users want to do are to compile examples, and that’s a harder problems since they need to be linked with variety of librairies. I also don’t see a reason for “installing” the library, the mere fact that you would be considering this suggests you don’t know enough about its ecosystem yet. It’s both discouraged and dangerous considering we don’t follow semantic versioning. The main recurring problem is that new users inevitably wants cmake stuff, they make PR before they understand the bigger picture well enough. My opinion is that once you see the bigger picture you would not consider a cmake file necessary anymore. I look forward to be swayed but right most of those cmake files are flawed, and informal poll with other librairies makers suggested that inevitably when they added cmake cruft the amount of cmake related noise and request would keep growing up to the point they regretted adding it. i am not firmly against it but i have yet to see a user caring about the right details. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, the above is for my project only. Definitely not reusable. I'll type up an example in a PR. It would not be the mess I have above which was only to hack this into a CMakeLists superbuild file for my project. It's installing into a prefix, which is thrown away after the project is built. This wouldn't be needed. |
Beta Was this translation helpful? Give feedback.
-
|
Sheesh, I spent some time on this and can't think of a good way to do it where the cmake won't have to manage dependencies like SDL or DX, locating libraries across different build environments. It works where the dependencies support cmake already like SDL but it won't work that widespread in a portable way. Then I was thinking - what if the cmake just exports lists of files required to be compiled for each backend? That works with FetchContent_Declare, which merges the variables into the current scope. I updated the superbuild I was doing above. That seems to be the least evil way for now for me to integrate with cmake given my love of superbuilds - which work well when using many different build systems - and my desire to not copy in the sources and compile them with my program at the same time. It needs no Cmake support in imgui to do that. It works fine across windows on msys2 and on Linux, I bounce between the two. I am sure it could be massaged to also work with visual studio and emscripten. Below is what I started which will work with FetchContent_Declare, I can't think of a clean way to get it working with ExternalProject_Add without making things worse. If someone could make it more flexible it might be worth it, to make integration with cmake a little easier. cmake_minimum_required(VERSION 3.12) if(NOT DEFINED IMGUI_BACKEND_SDLRENDERER3) set(imgui_base_sources function(assert_backend_not_set) function(assert_backend_set) if (IMGUI_BACKEND_SDLRENDERER3) assert_backend_set() set(IMGUI_SOURCES "${imgui_base_sources};${imgui_backend_sources}" CACHE STRING "IMGUI_SOURCES") |
Beta Was this translation helpful? Give feedback.
-
|
Just for reference, I usually pull stuff into a superbuild, where dependencies are built with ExternalProject_Add. and installed to a prefix, as it works generally universally across build systems and environments. Not specific to imgui. cmake_minimum_required(VERSION 3.10) Add ExternalProject moduleinclude(ExternalProject) SET(CMAKE_INSTALL_PREFIX ${CMAKE_BINARY_DIR}/install) #set library install path SET(CMAKE_VERBOSE_MAKEFILE TRUE) ExternalProject_Add( ExternalProject_Add ( ) ExternalProject_Add( ExternalProject_Add( ExternalProject_Add( |
Beta Was this translation helpful? Give feedback.
-
I saw tons of PRs for CMake examples. If CMake ever gets accepted, it would probably be better to just let the devs set feature variables that pull in different lists of CPP files to build the library separately, as imgui is supported on a wide range of platforms.
That basically mirrors the existing process - let the developers using imgui choose which files to compile for their project.
Ie, IMGUI_USE_SDL2, IMGUI_USE_SDL3, IMGUI_USE_DIRECTX etc. Set everything to false by default and put a comment in the cmake that the dev has to pass one in. It just would control lists of cpp files to include.
I am using imgui as part of a superbuild...as there's no build system I ended up just pasting this into my superbuild for my project. I usually have a common pattern of installing dependencies to a custom prefix as part of a superbuild and then my app uses those headers and libraries in the prefix.
CMake support would be nice but at least imgui is small.
There's many cmake PRs I see, one that doesn't do anything but put the onus back on devs like just using a bunch of settable variables above wouldn't be accepted, would it? If it has a shot, I could do it. It's not being overthought? A lot of libraries I see have very basic cmake support - they don't try to detect platforms, etc, they immediately put the onus back on the dev.
Such a cmake could further do less by just exporting an object library and headers to use in upstream cmakes, instead of supporting install. There should be some lowest common denominator of what won't create a support problem but still be useful.
ExternalProject_Add(
imgui
GIT_REPOSITORY https://github.com/ocornut/imgui.git
GIT_TAG v1.91.9b
DEPENDS sdl
UPDATE_DISCONNECTED TRUE
LOG_CONFIGURE ON
LOG_BUILD ON
LOG_INSTALL ON
CMAKE_ARGS
-DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX} # Set the install prefix
-DCMAKE_PREFIX_PATH=${CMAKE_PREFIX_PATH} # Set the prefix path to SDL
CONFIGURE_COMMAND "" # imgui has no CMakeLists
BUILD_BYPRODUCTS ${CMAKE_INSTALL_PREFIX}/lib/libimgui.a
BUILD_COMMAND ${CMAKE_CXX_COMPILER} ${CMAKE_CXX_FLAGS}
-I<SOURCE_DIR>
-I${CMAKE_INSTALL_PREFIX}/include
-c
<SOURCE_DIR>/imgui.cpp
<SOURCE_DIR>/imgui_demo.cpp
<SOURCE_DIR>/imgui_draw.cpp
<SOURCE_DIR>/imgui_tables.cpp
<SOURCE_DIR>/imgui_widgets.cpp
<SOURCE_DIR>/backends/imgui_impl_sdl3.cpp
<SOURCE_DIR>/backends/imgui_impl_sdlrenderer3.cpp
COMMAND sh -c "${CMAKE_AR} rcs <BINARY_DIR>/libimgui.a <BINARY_DIR>/*.o"
INSTALL_COMMAND ${CMAKE_COMMAND} -E make_directory ${CMAKE_INSTALL_PREFIX}/include/imgui
COMMAND ${CMAKE_COMMAND} -E copy <BINARY_DIR>/libimgui.a ${CMAKE_INSTALL_PREFIX}/lib/
COMMAND ${CMAKE_COMMAND} -E copy <SOURCE_DIR>/imgui.h ${CMAKE_INSTALL_PREFIX}/include/imgui/
COMMAND ${CMAKE_COMMAND} -E copy <SOURCE_DIR>/imgui_internal.h ${CMAKE_INSTALL_PREFIX}/include/imgui/
COMMAND ${CMAKE_COMMAND} -E copy <SOURCE_DIR>/imconfig.h ${CMAKE_INSTALL_PREFIX}/include/imgui/
COMMAND ${CMAKE_COMMAND} -E copy <SOURCE_DIR>/backends/imgui_impl_sdl3.h ${CMAKE_INSTALL_PREFIX}/include/imgui
COMMAND ${CMAKE_COMMAND} -E copy <SOURCE_DIR>/backends/imgui_impl_sdlrenderer3.h ${CMAKE_INSTALL_PREFIX}/include/imgui
)
Beta Was this translation helpful? Give feedback.
All reactions