Solvedlibui [POLL] Build system change

I had four reasons for choosing flat makefiles:

  1. I wanted libui to not have any extra dependencies (GNU make on Windows was already pushing it, but nmake is just way too primitive).
  2. I wanted to ensure that every generated file goes somewhere clean that I can predict away from the actual source code, in this case to just .obj and out directories (obviating the need for #13 in my opinion, at least)
  3. I'm not really a fan of other build systems to begin with, either because of their complexity or their mess (see point 2 above)
  4. I wanted to know exactly what was going on in the build process

However it seems that this decision is causing problems for lots of people, mostly on Windows where the command-line Visual Studio tools either behave unpredictably or require special handling depending on the configuration. @kainjow in #15 makes a really good point: most Windows users are likely more familiar with an IDE than with the command-line build system, to the point that command-line systems like cmake are more accessible.

While it's true I originally resisted changing, thinking make would be simpler, the number of build issues keeps growing, especially on other platforms. So now I'm willing ot hear arguments for specific build systems.

I genuinely do not have a preference for any one build system over the other, so please make your case for one you prefer. As part of your case, you should demonstrate what a setup for libui, the test/ folder, and each example would look like, as well as (if possible) a rule to build all examples. Feel free to point out any other advantages or disadvantages.

Here is a page detailing what an ideal build system would be like:

Right now the following are being considered:

  • cmake
  • waf
  • scons

I'll make my decision and switch build systems if one appeals to me more than the others.

Thanks for your feedback! I do appreciate it all, and I want to make sure libui works for everyone :)

59 Answers

✔️Accepted Answer

I'm maintaining my own CMakeLists.txt file here for ease of development for myself. I plan on adding Windows and GTK support to it when I get a chance.

Currently libui has nearly 20 files that are part of the Makefile. Using more modern versions of CMake (3.1 and later), you can manage multiple targets in a single file very easily.

Some examples of big projects using CMake are Qt and LLVM.

The great thing about CMake is it generates the cross platform projects for you, so one can work in Xcode, Visual Studio, Makefiles, Eclipse, and more.

CMake is fully open source. It can be built from source, or the binaries can be installed via Homebrew on OS X, Chocolatey on Windows, apt-get on Debian/Ubuntu, or downloaded directly for OS X and Windows.

With my example CMakeLists.txt file, you would put that in the root directly, then run these commands (minimum needed), which works on every platform (CMake will choose a default generator based on what it finds):

cmake .
cmake --build .

Other Answers:

on top of what has already being said, there are two reasons for me to prefer cmake:

  • it would make very easy to embed libui inside of projects that already use cmake. probably, without hurting the rest of the world.
  • most people know about it and you can compile cmake based projects without having to deal with the way a programmer found cool at the time he wrote the library.

i can live with libui's flat makefiles; i would prefer if libui would avoid "hesoteric" (for c++ projects) pre-processors, even if they are superior.
and i could have saved much time if libui were already using cmake...

Not so ideal from the perfectionist developer standpoint (bulky, somewhat overcomplicated and, like many build systems, is «a world of its own», requiring additional learning and reading manuals to be done for accomplishing something meaningful),

But for the average user it's perfect — self-contained, crossplatform and in most cases boils down to «mkdir build && cd build && cmake ../ && make». Also it's well documented, widespread and supported.

I'd also like to firmly advise against using:

  • «in–house» or «one man experimental project» systems. As cute, nice and cozy those are for their creators, for most devs it means additional trouble to bring those into project environment. As well as lacking or absent documentation, absence of support and no guarantees for forseeable future.
  • any system requiring infrastructure–tied language. This means waf, rake, qo (:D) or anything Python–, Go–, Ruby–, NodeJS– or Java–based. Yes, setting up whole installation of Ruby or Python (and then packet manager, and then packages and packages and packages), just for the sake of building small C/C++ project — it is a major pain in the… well, just the major pain, that is.

Honestly, I deeply prefer flat makefiles over most build-systems as well. But I have taken a special liking to tup. It builds incredibly fast, has brilliant dependency resolution, has incredibly terse build rule syntax, makes reproducible builds much simpler, is cross-platform and supports Windows, OSX and Linux.

The only things to know are that it is not makefile-generating, so it is a shift away from makefiles (where things like CMake are a layer on top of makefiles) and that it is truly a build-system and nothing more; e.g., it does not have install/uninstall rules.

In my personal projects, I tend to use Tup as my build-system and a flat makefile on top of it to deal with things like install/uninstall rules cleanly.

+1 for CMake from me.

I especially like the fact that it simply generates files for the platform's "native" build system, e.g. Makefile on Unix and a Visual Studio project on Windows.

Related Issues:

libui [POLL] Build system change
I'm maintaining my own CMakeLists.txt file here for ease of development for myself I plan on adding ...