CMake and CPack integration (removing Python dependency in the process)

[SamuelMarks]

Rewrote your Python code in CMake also.

[WiP: still some minor discrepancies in amalgamated nuklear.h to resolve]

Addresses (in part): #101 #103

[ghost]

This project focus on portability, efficiency and simplicity. There's no space for CMake

[SamuelMarks]

@HelloWorldlsla My interest in nuklear is keenly cross-platform.

Nuklear, IMHO, should be easy to build, test, and change. Its testing should be integrated with a CI/CD platform with status shown on GitHub (e.g, GitHub Actions, Cirrus CI, Travis CI, Circle CI, or other).

Platforms that I'm keen to test [and if needed, implement] support for include:

• Windows;
• Linux;
• macOS;
• iOS; and
• Android.

Stretch goals:

• FreeBSD;
• OpenBSD (curses?);
• SunOS;
• web.

CMake is merely one open-source cross-platform build system that works for all these platforms (or soon will, in the case of iOS).

GNU Makefiles unfortunately are not portable.

With a native first approach, which build system would you prefer using? - Maybe I can assist in contributing support for that one.

[dumblob]

Before going into the discussion about the general idea of getting rid of Python in favour of anything else (here cmake), I would like to point out that Nuklear has literally zero dependencies. It has only optional dependencies. So this is wrong. If vcpkg does not support optional dependencies, then we must not put any dependencies into the package description.

[RobLoach]

Agreed. These dependencies should be defined in the demos rather than here 👍

[dumblob]

@SamuelMarks cross-platform in case of single header libs (incl. Nuklear) means for me to have CI running on all imaginable platforms. Nothing more, nothing less.

I would like to understand a little more your point of view on this.

Could you elaborate a bit more why would you (pretty radically 😉) change the current state of things instead of just adding a few yaml/... file for CI to cover more cases? What was the motivation? Also what are the pros & cons of the approach you have chosen (compared to other approaches - at least to the current approach in this repo)?

Thanks!

[SamuelMarks]

@dumblob In terms of my [proposed] approach:

Pros

• Can build shared or static library instead of header-only;
• Testing can be more easily integrated with cross-platform package management and dynamic resolution of dependencies in a platform independent manner;
• Python is no longer required;
• IDE integration;
• Modularity (can take parts of this project and reuse them—in part—elsewhere).

Cons

• People seeing CMakeLists.txt files might immediately assume the project is complex.

[JackBoosY]

Any progress?

[dumblob]

Thanks @SamuelMarks for the pointers! Let us discuss this to set a deeper mutual understanding.

Pros

• Can build shared or static library instead of header-only;

Any real use cases? After those years with header-only libraries I could not find any real use case for making them a shared/static library.

• Testing can be more easily integrated with cross-platform package management and dynamic resolution of dependencies in a platform independent manner;

Do I understand this correctly that this point solves only new problems originating from supporting the first point - namely building as shared/static lib?

• Python is no longer required;

But cmake is 😉. IMHO both (Python and CMake) are fine so I do not consider this point a pro nor a con.

• IDE integration;

This sounds interesting as I am not much experienced with modern IDEs. Do modern IDEs have issues with header-only libraries? Could you list those isusses? Any other approaches to solve them (and their pros & cons)? Or could you generally elaborate? Thanks!

• Modularity (can take parts of this project and reuse them—in part—elsewhere).

If you compare the modularity you envision with the current modularity (i.e. source split into logical blocks mostly individually reusable as seen in https://github.com/Immediate-Mode-UI/Nuklear/tree/master/src ), could you list all the differences you see and why they are important (or alternatively the pros & cons of the current modularity)? Thanks!

Cons

• People seeing CMakeLists.txt files might immediately assume the project is complex.

Ok, but not a big issue IMHO 😉 (definitely not a reason to not merge the PR).

Let me point out one more thing - I am pretty sure we can not maintain multiple build systems for the example/ directory and the few backends which do need special compile-time treatment (for anything else we do not need any build system as everything is "header only"), so we would need to provide either cmake or make support as an officially unmaintained "contributed" code (perhaps in a contrib/ directory).

Thoughts?

Btw. could you take a look at the deps in vcpkg.json as that is definitely a show stopper as I wrote in my earlier reaction (and "resolve" the conversation)?

[RobLoach]

I understand glob is frowned upon in CMake, but it may help ease the maintenance of the CMake definition files.

[learn-more]

The reason why glob is not recommended is because it is slower, and when there is a file added or removed you do not trigger a cmake rebuild.

Instead of using glob, I would suggest to format these lists differently (one file per line) so that editing the list results in cleaner diffs.

[RobLoach]

Possibly have these as individual options defaulting to if the platform dependencies are found?

[RobLoach]

Could have the BUILD_DEMOS and BUILD_EXAMPLES options enabled only if the user is using CMake from root. That wasy it'll only build them if you're building locally rather than as a third-party dependdency.

[RobLoach]

This can be accomplished with...

# Options
if ("${CMAKE_SOURCE_DIR}" STREQUAL "${CMAKE_CURRENT_SOURCE_DIR}")
    set(NUKLEAR_IS_MAIN TRUE)
else()
    set(NUKLEAR_IS_MAIN FALSE)
endif()
option(BUILD_DEMOS "Build demos" ${NUKLEAR_IS_MAIN})
option(BUILD_EXAMPLES "Examples" ${NUKLEAR_IS_MAIN})

[RobLoach]

Since VERSION won't match, possibly remove it?

Suggested change

	project(Nuklear VERSION 0.0.1 LANGUAGES C)
	project(Nuklear LANGUAGES C)

[learn-more]

This could be made the primary place for the version?
Then it generates a header with the version in it, so that compile-time you have access to the same version.

[RobLoach]

Just a note that I'm slowly growing as a CMake fan, and found it does make a few things easier. Particularly when it comes to dependency management.

I could not find any real use case for making them a shared/static library.

Building as a shared library does improve compilation performance, as you don't have to compile directly into your application. While the majority of cases are static, it doesn't hurt to have the option. Don't think we really need it right now though. It's definedin that NOT BUILD_HEADER_ONLY condition. https://github.com/Immediate-Mode-UI/Nuklear/pull/462/files#diff-148715d6ea0c0ea0a346af3f6bd610d010d490eca35ac6a9b408748f7ca9e3f4R32

IMHO both (Python and CMake) are fine

I think having both in the mean time is a good option. Just grows the potential contributor base.

Do modern IDEs have issues with header-only libraries?

Generally, IDEs don't have issues header-only libraries. The benefits in the IDEs with CMake comes in providing the build commands directly through the user interface. VSCode, for instance, will find the available build targets, and give you a one-click button to build the target automagically.

People seeing CMakeLists.txt files might immediately assume the project is complex.

One thing we could do is limiting the places where we throw the CMake definition files. Keeping to jsut the root CMakeLists.txt and src/cmake or something could help isolate the exposure to the files living everywhere.

we would need to provide either cmake or make support as an officially unmaintained "contributed" code

Perhaps a slow transition? There is still work required to get this to a place where it matches the build processes that exist in there currently.

[dumblob]

If we isolated cmake support in contrib/ directory, would IDEs etc. pick it up to not lose (as I understand it) the only advantages cmake offers on top of the current state in this repo?

(If someone really needs a shared lib there is nothing easier than to write my.c file with #include "nuklear.h" and compile & link it themselves as usually; so supporting a shared lib in any header-only project, incl. Nuklear, still sounds weird to me.)

Admittedly I am reluctant to remove support for make as Nuklear is still kind of a simple library. To get Nuklear one needs git one way or another (actually not - there is a download button on Github page 😉).

That means git-for-windows on Windows (on other systems git & make are in 99.9% cases preinstalled). And git-for-windows contains everything needed - make cc etc. except Python. And that is my only pain point which I still can not find the time to solve - namely to rewrite the amalgamation python script to sh and embed it into a Makefile. Thus everything else (cmake files, etc.) shall IMHO be in contrib/.

What do you think?

[SamuelMarks]

@RobLoach @dumblob Thanks for the feedback.

Possibly hiding everything behind option is a good idea. Although Nuklear is header-only, it's not [always] clear how to configure it for this environment or that environment. My contribution; albeit incomplete; tries to place CMake at the centre of all configuration in Nuklear.

This migration should also simplify CI/CD and addition of new "backends".

As for where to place all the CMakeLists.txt files, you could place them all in a cmake folder (except one, the root one)… but then it might not be clear to new contributors that when they change something in the project they also need to update the CMakeLists.txt. You can kind of think of it as __int__.py in Python. You technically don't need any of them, and can build out "modules" by globing through Python files from the $search_path down.

Finally the shared/static and header-only/header-src toggling is an interesting one, which should enable a great number more use-cases and also optimisations (remove support for "backend" that aren't being used).

[riri]

Ide specific folders should be in your global git config, not per project (that includes .idea, .vscode, etc..)

[riri]

I am a fervent user of CMake, and even have my method to use single header libraries with it.

The only thing is that introducing CMake in a project like Nuklear will be quite complicated if you want to make it powerful.
First one has to decide which feature to enable :

• just a tool to build the release: even if I hate python and would love to see it dropped from the source dir, I'm not sure CMake is better in this case (I mean if we are objective, replacing the Python dependency by the CMake one is not better for one who does not use any of them).
• provide an INTERFACE library: that's the most interesting usage as nuklear can be more easily integrated in projects already using CMake, while keeping the single header behavior (goes well with git submodules and CMake's FetchContent module). For those not knowing that feature, think of it like a fake library giving compiler options to users on inclusion). this CMakeLists.txt shows a usage of Nuklear in another project (just a sample in this case). Then user just has to link an INTERFACE library, and all include dirs and compiler options (if set in the CMake target) are resolved.
• provide the static library option : that really becomes complicated because of all options to manage to make it versatile like dirty copy of files in my project
• the shared library option: I can't even think how that could be useful, please help me to understand :)

Plus, managing all possibilities for demos will harden the task, and will be a nightmare to maintain. So my opinion is to not include CMake in Nuklear, but maybe provide an example project aside (another repository) which uses Nuklear and builds demos and all.

[SamuelMarks]

@riri Removing Python dependency and adding CMake dependency does clean things up in terms of configuration (one tool for configure ; same tool for build ; sister tool for packaging [CPack] ; sister tool for testing [CTest]).

The shared library option would be useful for reducing build times and enable a plethora of different deployment use cases including:

• Upgrade all GUI programs installed in environment by replacing one file
• Simplify generation of bindings for other programming languages (what's exposed in the shared library is [likely] what you want exposed in each language)
• Reducing build times
• Simplifying the inclusion of third-party dependencies (Nuklear and the backend of your choice),
• ^including at install time allowing the users to pick which backend to use, and even trying multiple in turn with successive dlopens (or equivalent).

…in terms of INTERFACE vs STATIC vs SHARED: agreed. The idea however would be to put that under an option similar to BUILD_SHARED_LIBS

Testing is a nightmare; agreed. CMake helps to centralise all the configuration, and combined with CTest and a CI/CD builtin to this repo one can do most of the testing. I've seen some GUI framework developers add in some ML and do object recognition to headless test UI drawing and interaction on "screen". Naturally we would run this on every supported OS and backend combination.

[riri]

@SamuelMarks I totall agree with all of your arguments, and CMake is great for managing projects industrially.

But I'm still thinking it's better to define a CMakeNuklear repository which provides all those features, and keep the Nuklear one lean and mean, in the kiss philosophy. In this regard, I'm more on the side of @dumblob.

We would have then:

• Nuklear - A single-header ANSI C immediate mode cross-platform GUI library
• CMakeNuklear - integrate Nuklear in your project with CMake (and checking your PR, you went quite far!)

Remains the question of the algamatron. Maybe having a simple CMake setup in Nuklear just to provide this tool and and simple definition of an interface library could suit, keeping more advanced stuff on the aside project I mentionned ?

[dumblob]

Possibly hiding everything behind option is a good idea. Although Nuklear is header-only, it's not [always] clear how to configure it for this environment or that environment. My contribution; albeit incomplete; tries to place CMake at the centre of all configuration in Nuklear.

I am not experienced with cmake but this sounds a bit like a diversion from the current course of the Nuklear repository 😉. But I understand that this might be what IDE users expect. In which case - considering the "intrusiveness" (see below) cmake demands I would lean towards creating a separate repository (perhaps Nuklear-cmake) just with cmake stuff as @riri suggested. This separate repo would have independent life cycle and allow this original Nuklear repo to stay the single source of truth.

This migration should also simplify CI/CD and addition of new "backends".

So far I can not remember any make-related or build-tooling related issues to overcome (to me it everything always felt pretty "minimal effort" which would be hard to improve on disregarding whether by cmake or anything else). If there are any, please speak up 😉.

As for where to place all the CMakeLists.txt files, you could place them all in a cmake folder (except one, the root one)… but then it might not be clear to new contributors that when they change something in the project they also need to update the CMakeLists.txt. You can kind of think of it as __int__.py in Python. You technically don't need any of them, and can build out "modules" by globing through Python files from the $search_path down.

Yep, this is in line with my limited cmake experience. One word: intrusive. Cmake was and still appears to be intrusive. I think a separate repo might be the best of both worlds - easy to use in line with cmake practices and easy to maintain independently but still as part of the Nuklear project.

Finally the shared/static and header-only/header-src toggling is an interesting one, which should enable a great number more use-cases and also optimisations (remove support for "backend" that aren't being used).

Well, there is no such thing as "support for unused backends" - there is always only one backend without any need to remove anything. Could you explain a bit more about this "removal of unused backends"?

Thanks!

[dumblob]

Btw. thanks @riri for the link https://github.com/riri/using-shl/blob/main/src/shl/CMakeLists.txt - that is how I originally envisioned cmake users use single header libs.

But as I said, I have limited experience with cmake projects in the wild so I depend on judgements of you all here 😉.

[dumblob]

I forgot to mention that I would prefer to have amalgamation to be as portable as possible - as I outlined above in #462 (comment) I think the best way would be to rewrite it to POSIX sh (no bash nor anything else). That should work with cmake well enough.

We can then even decide whether we shall embed the amalgamation script into Makefile or leave it separate (I am fine with either).

Thoughts?

[SamuelMarks]

@dumblob POSIX sh is portable, but it looks like cmake is more natively portable especially when considering Windows. There is no emulation done, it's just #ifdef for different OSs.
…and you can technically do it without any incorporation of other CMake stuff just by reusing what I've done.

My PR isn't necessarily the most concise solution, and yes having CMakeLists.txt littered throughout your codebase is an annoyance. But there are significant benefits.

I am using the word "backend" to refer to the directory names in https://github.com/Immediate-Mode-UI/Nuklear/tree/master/demo

One of the major reasons I wanted to integrate CMake is to simplify the inclusion of different "backends" integrated into vcpkg. The others are:

• integration with IDEs;
• cleaner inclusion as a 'port' in vcpkg;
• shared/static/header-only switching;
• packaging simplification;
• simplification of generating wrappers for other programming languages;
• removal of Python dependency;
• simplifying adding new backends;
• simplifying testing of all supported backends on all supported platforms in a CI/CD environment.

I still think having all the CMake files in this repos to be a good idea. The root CMakeLists.txt and everything else under a root cmake directory is fine. I just don't want to be in a situation where this repo and the CMake repo deviate ("drift"). A PR to one will now oft-require a PR to another :. And the CI will [likely] run in my CMake repo rather than yours. Or we'll need to configure a bunch of bots to pull in my repo run the tests with your repo on every PR and not allow merges until resolved. Which will be more annoying because if they add a new file/folder they'll need to send a PR to the CMake repo first, then to yours, and if you reject it then I need to revert it (or delete the branch or whatever). Lots of work to avoid having a cmake folder and CMakeLists.txt in the root of your repo…

[riri]

I forgot to mention that I would prefer to have amalgamation to be as portable as possible - as I outlined above in #462 (comment) I think the best way would be to rewrite it to POSIX sh (no bash nor anything else). That should work with cmake well enough.

We can then even decide whether we shall embed the amalgamation script into Makefile or leave it separate (I am fine with either).

Thoughts?

I'm quite confident with the POSIX sh solution, even if that means some minor modifications in source files. For windows (when not using mingw ), I'm sure a powershell expert could do it. I don't think we need more for rebuilding nuklear.h, once the correct script is written.

edit: it's hard commenting from the phone with autocorrection :)

[riri]

@SamuelMarks for ci/di you mark a point.

The most important is to not impose cmake to every user, but provide it as an alternative. So I'm splitted 😃

[chaoticbob]

Random 2 cents here...as a possible new user to Nuklear, was a bit surprised the demos didn't have any popular build system support. The Windows based samples have the .bat files but a lot of them are for VS2015? This is a tad old. Yeah, I know I can change those to be whatever version of VS I had, but it would also be cool to be able to do something like:

cmake -B build-vs2022 -G "Visual Studio 17 2022" -A x64

...to generate build files for Windows and just proceed to checkout what Nuklear has to offer.

Having read through this thread, I can kinda see where everyone is coming from. But honestly, not having CMake support (or some build system) just makes the getting start unnecessarily cumbersome. As random dude on the interwebs that uses CMake, I find a lot of what @SamuelMarks said is very sound and reasonable.

Having CMake doesn't necessarily create dependencies unless you want it it to.
Having CMake could also make integration of Nuklear into projects easier...should that be desired.
CMakeLists.txt in the root with optional cmake dir seems to be the path of least resistance - doing otherwise just normally ends up creating something unmanangeable.

A lot of projects have CMakeLists.txt in the root as a possible build path or just an easy path to build samples, demos, etc. You could also provide different flags to build with/without GLFW support so that all the GLFW based samples could be optionally built if desired.

And lastly, SAY NO TO GLOB!

[RobLoach]

I'm in favour of moving from our custom Python and build scripts to something a bit more standard. There are a few improvements to this PR that could be made, but I don't think that should stop us from moving in that direction.

@SamuelMarks Do you have any plans to make updates here? If not I could help pick up a few of the pieces.

[SamuelMarks]

Sure I can finish up here. In a few days one of my paying clients is paused until January 10 so this is a good period to work on this (and other things!).

Just start replying with wishlist & fixlist and I'll incorporate and also finish up the whole option based flag system I had envisioned.

[dumblob]

Hi everybody! Sorry for not getting involved earlier. It seems my time capacity did not change for the better and I anticipate this to continue. So as a dinosaur among modern devs here, let me summarize my vision regarding CMake:

1. Yes, go ahead!
2. Contributors (incl. those contributing to nuklear.h) must not need to touch cmake (nor run it locally) at all - CI/CD etc. will do all of this for them. This is to keep the lowest possible barrier for contributors.
3. It must be sky clear from the repo Nuklear is a header-only lib and thus there is no need for any build/make system.
4. It is clear to old-schoolers like me how to compile the demos just by reading the sources in the repo (i.e. without having cmake installed and run). This is to allow non-Cmake users to copy/extract the necessary portions from CmakeLists to their own Makefile etc.

Nice to have:

1. Remove anything else than Cmake (i.e. Python, shell, Makefiles, etc.) unless there is no duplication (e.g. during the transition phase from Makefile to Cmake, or for other reasons - even permanent reasons).
2. Revamp readme - explain what are single-header libs, what are "demos" vs. "examples", hint for dinosaurs how to extract the necessary bits from CmakeLists 😉, etc. Also emphasizing Cmake is and never will be essential for Nuklear yet it provides nice integration with modern dev tooling.
3. Maybe pregenerate common build systems for example/s for a few platforms (e.g. Windows10 on x64, macOS M1, Linux x64 glibc 2.36). Maybe this point is a bad idea though...

[learn-more]

Would it make sense to conditionally include CTest only if testing is enabled?

[learn-more]

The CMakeLists.txt for all these demos are possibly going to be 90% the same, would it make sense to add a cmake function/macro like add_nuklear_demo(SOURCES xxx LIBS xxx) for convenience?
(And so that when projects are grouped with something like set_property(TARGET gdip PROPERTY FOLDER "Nuklear/examples") this only has to be done in one place?

[SamuelMarks]

Contributions welcome

[learn-more]

How do you propose to do this, send a PR to your fork?

[RobLoach]

I'm happy to bring the branch into the repository too, if that makes contributions easier.

[SamuelMarks]

I'm happy either way