Provided CMake, Makefile and example demos have a very confusing build structure

[jackleberryfin]

This is in relation to how ImGui is built and run on various platforms and is probably more of a complaint unfortunately.

As someone who uses CMake quite a bit in a professional setting, i am a little bit shocked that:

• A) There are any Makefile examples outside of a readme or compatibility documentation.
• B) CMake toolchain files are not being used to completely make all the example directories redundant. I havn't checked but i assume the bulk of the demo code is identical and makes no sense to have these duplicated in separate example folders.
• C) Imgui framework isnt in its own folder with a cmake structure to build an ImGuiFramework .lib, .dll, .a or .so
• D) Each backend renderer isnt in its own folder with a cmake structure to build a ImGuiBackend .lib, .dll, .a or .so
• E) The build process isnt the following:

1. Select the Cmake toolchain file (apple, linux and windows could easily be provided).
2. Ensure the variable in the toolchain which points to the backend which is compatible and installed on your system is identified. Options available to change the compiler toolchain as well. The identified variable for the backend will dictate which backend is discovered during cmake configure. Optionally: The backend variable could be defined at the top CMakeLists.txt file in the repo, these options are really easy to have configured from vscode settings.json as well.
3. Build.

Note: The CMakeLists.txt file in the SINGLE example code source directory links to the ImGui Framework and to the variable which points to your configured backend variable from the toolchain.

Any development of this ImGui into a product need only the toolchain file, client/product source code, ImGuiFramework.so, backend.so. I really hope it is evident how this would improve upon the provided repo structure and aid in developers (novice to advanced) get your excellent repo working quicker and more easily. It is a slightly confusing task to separate ImGui Framework from the ImGui demo code. These are 2 entirely different objects and should be clear separations enforced.

[jackleberryfin]

Recommending closing, as the majority of what I discussed would be quite difficult due to the variability across platforms and renderers.

[ocornut]

I discussed it a little bit in #7892
3.6. Lack Of A Build System Is A Feature

I need to stress that i am not in principle against providing cmake files but i believe people who write them are thoroughly disconnected from the reality of what it takes to compiles and link against a dozens windowing/graphics library which for many have no standard way of being acquired.

[jackleberryfin]

I have experienced and observed this lack of low level workings knowledge and think I share some of your concern. I have just now perused a few of the cmake PRs and haven't really seen anything like how I would write a cmake structured project. Not really a fan of any that I saw. Perhaps I will put a few hours into restructuring the project and see what you think. I have written some crazy complicated cmake build systems ... but I think the opposite would be better in this case.

I will have to look into your CI/CD pipeline to see how you're building each platform/backend combination .. if you are.

[ocornut]

I will have to look into your CI/CD pipeline to see how you're building each platform/backend combination .. if you are

We are but it doesn’t relate much to the problem. It’s easy in our CI context to acquire libraries in whichever way works for CI. It doesn’t mean it would align to how end user would acquire library.

Last year I did an informal twitter poll on this topic and a very common answer was library maintainers who regretted adding a cmakefile to their lib because in their view it ended up increasing their maintainance cost: people keep coming with edge cases.

I would very happily support and link to one or more repositories that provided external cmakefiles for whatever imgui supports.

i should also add that as i am exploring using vs code on a Mac I will inevitably be forced to confront cmake a little more myself.

[jackleberryfin]

Yeh im using cmake on mac with vs code.

[ocornut]

I basically think there is no good solution to this problem, and that people who claim/think they have a solution are most of time introducing new constraints which are not to the taste of some of the user base.

I’m trying to be open minded to proposals but the fact that no one agrees on anything (“haven't really seen anything like how I would write a cmake structured project”) when it comes to making a cmakefile is a strong indicator that the system is not adequate.

[ocornut]

have glfw + opengl 2/3 building with the demo example in a very compartmentalised and standardised way.

If you think there is a standardized way to use GLFW I am afraid you are misunderstanding the problem. :(

[jackleberryfin]

Hey, do you know if the code in example_apple_metal actually runs? i've got it building fine but it hangs in NSApplcaitonMain seemingly. Maybe ill leave that alone for now.

I've got all other builds running on MacOS. < 0.6s to build any combination of Platform impl + Renderer + demo, changing renderer is < 0.2s rebuild as its not rebuilding the platform impl, framework or demo components components (just main).

Super simple to select which configuration to build, set one variable for (glfw/sdl2/apple) and another for (metal/vulkan/opengl2/opengl3/ .. etc)

[jackleberryfin]

I don't have any interest in how to use GLFW.. i wouldnt know where to even start, just interested in the build process.

[ocornut]

By "use" I meant "use as part of building an app". Where are you pulling GLFW from?
I'm honestly not hopeful of this going anywhere so I am not expecting you to put energy on it, it's likely to end up like the 15+ other PR.

[jackleberryfin]

installed glfw from homebrew i believe and located within cmake by find_package.

[jackleberryfin]

#8012
Draft PR created.