Suggesting Ninja on README.md?

[ebraminio]

Bike-shedding anyway, libui can be built faster and easier with cmake -Bbuild -H. -GNinja && ninja -Cbuild, maybe this (or just its -Bbuild part and no ninja build) can be suggested instead current mkdir build & cd build && cmake ..?

[andlabs]

If those flags bypass the need to explicitly make the build folder, that's cool.

I'm rapidly losing my patience with cmake. If cmake is generating ninja files for libui fine, then it will work; I've heard that libui Visual Studio projects don't work correctly, though... The docs I stated are how I personally build libui, but given cmake does support multiple backends, it shouldn't be the only way. I have considered meson, but the Python dependency, ninja requirement (for the same requires-an-extra-external-dependency reason), and amount of behind-the-scenes magic stuff doesn't seem appealing (which is also a concern I have with cmake)...

[ebraminio]

cmake -Bbuild -H. && make -Cbuild also can be used it seems

[refi64]

Question: ever tried Meson? It's rapidly gaining popularity, and it's now being adopted by GNOME, systemd, libfuse, and many other prominent projects.

I'd also love to toot my own horn here a sec...

[andlabs]

I have considered meson, but the Python dependency, ninja requirement (for the same requires-an-extra-external-dependency reason), and amount of behind-the-scenes magic stuff doesn't seem appealing (which is also a concern I have with cmake)...

Elaborating on the first two points: Ideally libui should require no dependencies other than the basic build tools to run. This is why I tried to use Makefiles only initially. This turned out to grow into a massive multifile conditional mess that necessitated GNU make. Which was fine for every platform except Windows. But I assumed that wouldn't be too much of an issue, as I assumed that a) MinGW would come with GNU make, and b) MSVC users could just run the build_w32.bat batch file included in the GNU make source code from a Visual Studio command prompt to build GNU make instead, since that also didn't require anything other than Visual Studio and the GNU make source code. This did not happen: instead, people got confused trying to set up GNU make on Windows, and then everyone on all platforms started having weird problems with the Makefiles I had that I couldn't reproduce anyway. Switching to another build system was not a tenuous choice, and I didn't want to overcomplicate the build process by requiring even more dependencies that you need to install before you can build. And Meson has two dependencies: Python and Ninja. And some people do argue that Python is on every computer anyway; those people forget that Windows does not come with Python, and if Meson ever switches to Python 3, then systems that only ship with Python 2 (which IIRC is macOS, but I could be wrong) become a problem! (Also there was a point when GStreamer needed a newer version of Meson than what shipped with what was then the upcoming version of Ubuntu. That was fun.) And yes, the meson folks will tell you that Ninja is written in C++ and can easily be built for an OS that doesn't have it and then put on the package management system of that OS (where applicable), etc. But then I would again point you at my GNU-make-on-Windows argument above.

Now, am I overreacting or trying way too hard to do the impossible, or am I even exaggerating the numbers of affected people? Maybe. I really don't know. libui is probably trying to be too much anyway, and there's probably a good amount of libui's history as a library specifically for the Go programming language coloring my requirements in this department (this is the biggest reason I personally have for maintaining libui static builds, for instance; I forget why other people wanted them too, or why I decided not to go with just requiring shipping DLLs with Go binaries...). Plus, I've forgotten the specific issues people had with the Makefiles.

But the magic stuff is still an issue I'm not particularly happy with. CMake's half-documented-ness and necessity of magic incantations under completely undefined circumstances have bitten me too many times at this point. This issue and its many duplicates still aren't adequately resolved, and I'm not even sure there is a way to adequately resolve it (even with a new build system, but that's another discussion entirely relating to how Windows linkers work; maybe this could have a way out? IDK). And now with the paste I linked above, I have a behavior they are saying will be removed from a future version, even though I have a cmake_minimum_version() clause at the top of my CMakeLists.txt that should mean the exact opposite. And what's worse, that log does not tell me what I should be doing to fix this correctly.

With both CMake and meson, and likely with all these other popular build tools, you don't seem to control what build options and modes are available out of the box. For meson, you can add to that list, but you can never really know what the full list will be at any point in the future. And I'm definitely not a fan of having to specify build options in a separate file. meson even seems to require you to specify the values for those options in that same file before running meson for the first time! I could be invoking it wrong, though... It also assumes that all threading is the same on a given platform, which I know isn't true (but sadly is true for some platforms, like macOS, where the kernel data structure for threads is literally identical to the definition of pthread_t and pthread_create() is just a thin wrapper around the appropriate system call with some extra bookkeeping in user mode).

Yes, I know these complaints are not particularly well defined, but I haven't looked at a new build system in a while, as I'm currently stymied by needing copyright clearance from my new job to continue developing libui as my own. If this info was still fresh in my head, I'd be pointing out specifics. Sorry.

I don't know what to say about your tool; I would have to look into it. In the meantime, I've been thinking about a hypothetical build system that would have to both require you to specify every detail AND know what those details mean and what consequences they would have, and if the latter is even possible... and whether such a build tool would Just Work for the people who had trouble with my Makefiles.

Or am I just overly paranoid?

[refi64]

puts on build system nerd hat

If minimal dependencies is your goal, Boost.Build should only depend on a C compiler. Over time, it's gotten mixed reactions, but IMO it's significantly better than CMake.

One thing I do want to add to Fbuild at some point would be a Windows .exe file containing Python inside, so there'd be no need for a separate interpreter. That being said, the last release was several years ago (it was dying a bit before I offered to pick up maintenance), and I'm not sure I'll be able to fit this into the next one (which is already incredibly huge to begin with).

If you're really focusing for a build tool that's really all-encompassing, there's Tup...but you'd have to configure the builds by yourself, and it doesn't play too nicely with some build tools. Shake is another awesome one that's plagued by the fact that it requires Haskell (talk about a big dependency).

I don't know why the hell I know all this stuff.

[andlabs]

More cmake notes: https://cmake.org/cmake/help/v3.5/variable/MSVC_VERSION.html

[andlabs]

With the switch to Meson I'm now forced to use Ninja anyway, so this is done.