Switch from cmake to premake5

[Quaker762]

This one's probably just more of a personal preference, but I'd like to garner some opinion of others. I've done a bit of experimenting with premake5, which is similar to cmake, however a lot less complex. The scripts are basic .lua scripts, that look similar to the one attached. One neat feature is the ease of specifying build targets, as well as allowing recursive file finding (e.g files {"source/sh3/**.cpp", "source/sh3/**.hpp"}) instead of having to specify files we want to compile. Though simpler, however, there IS a lot of functionality that it does not contain that cmake does, such as initial compiler scanning etc.

An example of a script can be found here: https://github.com/Palm-Studios/OpenHill/blob/master/premake5.lua

[z33ky]

I've chosen CMake because afaik it either has support or is supported by the most IDEs. It's not necessarily as good as a "true native" project file, but probably better than no integration at all.
I've worked on projects before where there were just 5 or something project files that needed to be kept in sync, so I accepted the horribleness that is CMake to at least just have a singular place.
I have some hopes for meson. This build-system is explicitly looking into ways to enable IDEs to integrate meson (see IDE integration). Sadly it is still rather young and not widely supported.
It uses a Python-like language, but is not turing complete (see Why is Meson not just a Python module so I could code my build setup in Python?).

Note however that meson does not support wildcards for source-file specification (FAQ entry).

I have not used premake before, but like Lua. Well, most of it anyways *mutters about 1-based indexing...

I have written a meson.build file for a project that features the same warning-flag checking as our current CMakeLists.txt: gist. I've written it to resemble the CMakeListst.txt, so it might not be considered good style for meson.

[Quaker762]

I've chosen CMake because afaik it either has support or is supported by the most IDEs. It's not necessarily as good as a "true native" project file, but probably better than no integration at all.

From what I can see this is the case, albeit somewhat broken on most of them, especially when it comes to Windows. I vaguely remember codeblocks giving me some kind of issue with it's cmake plugin.

I have some hopes for meson. This build-system is explicitly looking into ways to enable IDEs to integrate meson (see IDE integration). Sadly it is still rather young and not widely supported.
It uses a Python-like language, but is not turing complete (see Why is Meson not just a Python module so I could code my build setup in Python?).

I have written a meson.build file for a project that features the same warning-flag checking as our current CMakeLists.txt: gist. I've written it to resemble the CMakeListst.txt, so it might not be considered good style for meson.

That looks pretty cool actually, the syntax to enable/check is quite similar to what you'd expect in a premake file.

I have not used premake before, but like Lua.

From the extent that I've used it, it's rather nice. It's smart too, as it can resolve libraries that you make. That is, if one of the projects you specify is of type StaticLib (like in the example I posted) it's able to automatically resolve the path when you want to link it against you're executable. Also the ability for it to recursively search directories for source files is excellent.

Well, most of it anyways *mutters about 1-based indexing...
Like Matlab.. Ew..

[z33ky]

From the extent that I've used it, it's rather nice. It's smart too, as it can resolve libraries that you make. That is, if one of the projects you specify is of type StaticLib (like in the example I posted) it's able to automatically resolve the path when you want to link it against you're executable.

Meson does that too and I thought CMake as well.

Also the ability for it to recursively search directories for source files is excellent.

I assume it does come with the downside mentioned in Mesons FAQ though.

The issue of a missing source file in the build script should be quite apparent. It is convenient, but does not lead to difficult-to-debug problems and comes with the aforementioned downsides.
CMake can also glob for source files, but I have deliberately avoided using it.
I might also on occasion have some stubbed test code lying in my source-folder that I build in favor of the actual project, which I would have to move or rename in order to build the whole project, though I suppose that'd be on me.
I am not vehemently opposed to using globs for that propose, I just want to voice my concerns.

I don't think meson is going away as it has been picked up by a couple of projects. It has a better plan for IDE integration than CMake, by providing an introspection tool and JSON output describing the project, and also the prospective rewrite-tool that shall take care of adding and removing files from a project programmatically.
Right now though the IDE support is sparse and I am neither optimistic nor pessimistic about future growth in that area. It certainly has great potential.

There are also plans for meson (and currently an experimental implementation) to have a tool that can add and remove source files from a meson.build-script, so that when a user has generated a project for their IDE, the IDE can also keep the script in sync with the changes the user makes to the project, at least as for adding/removing source files - not so for compiler flags.

Do you know if premake has similar goals regarding IDE support?
Even though I don't use an IDE, I want a build-system that allows other developers to use their tools the way they always have. I wouldn't even say that CMake has failed us in that regard, since the dependencies are the problematic part. The imported targets vs the old way of defining an LIB_INCLUDE_DIRS and LIB_LIBRARY has been problematic though (see 548b538), though we could also side-step this by just requiring a sufficiently recent CMake.
To be fair, meson does not produce Makefiles, however I don't think it's a big issue to type "ninja" in place of "make" or teach your editor to do that.
premake has definitely been around longer than meson, though I still have not seen it much. I mostly see autotools and CMake, occasionally waf and sometimes even just a Makefile. And of course also those that just commit their project file for MSVC or Eclipse or whatever.

[Quaker762]

Meson does that too and I thought CMake as well.

This I didn't know (with regards to cmake).

I am not vehemently opposed to using globs for that propose, I just want to voice my concerns.

I didn't think of this, mostly because when working by myself it's an assurance that the sources are always there and there's no missing files, however I can see that being an issue on a distributed project.

I don't think meson is going away as it has been picked up by a couple of projects. It has a better plan for IDE integration than CMake, by providing an introspection tool and JSON output describing the project, and also the prospective rewrite-tool that shall take care of adding and removing files from a project programmatically.

That sounds pretty neat, I hadn't heard of it until now, but I'm already liking the syntax and the feature set they plan to implement.

There are also plans for meson (and currently an experimental implementation) to have a tool that can add and remove source files from a meson.build-script, so that when a user has generated a project for their IDE, the IDE can also keep the script in sync with the changes the user makes to the project, at least as for adding/removing source files - not so for compiler flags.
Do you know if premake has similar goals regarding IDE support?

From what I've read (https://github.com/premake/premake-core/wiki/Using-Premake) it generates project files instead of having actual 'integration' per se. Handy for us in that it supports gmake files, and handy for Windows users with vs05+ IDE support for all flavours of Windows. Apart from that, it's basically just a C command line program that's small in scope.

The imported targets vs the old way of defining an LIB_INCLUDE_DIRS and LIB_LIBRARY has been problematic though (see 548b538), though we could also side-step this by just requiring a sufficiently recent CMake.

Yeah I definitely agree. Also, as a side, target import for sdl2 is currently broken on arch and has been for the past 8 months (one of the few reasons I took a break from working on this, actually). It can't find the proper include directories apparently.

[z33ky]

Many platforms do not provide a system package manager. On these systems dependencies must be compiled from source. Meson's subprojects make it simple to use system dependencies when they are available and to build dependencies manually when they are not.

https://mesonbuild.com/Dependencies.html#building-dependencies-as-subprojects
That's a great fit to fix #137.

Sadly, meson cannot communicate with other build-systems, like CMake's ExternalProject can. However, there is mesonbuild/meson#4321. Until then we can maybe write dummy-meson.builds that use run_command and assume the system compiler is fine.
We will also have to recursively build our dependencies' dependencies.

[Quaker762]

https://mesonbuild.com/Dependencies.html#building-dependencies-as-subprojects
That's a great fit to fix #137.

Yeah definitely, I'm thinking this is going to solve the issue of per platform building once and for all, especially if it will allow Windows users to join development finally.

Sadly, meson cannot communicate with other build-systems, like CMake's ExternalProject can. However, there is mesonbuild/meson#4321. Until then we can maybe write dummy-meson.builds that use run_command and assume the system compiler is fine.

As per usual, I'll leave this to you, though I'm not too worried about that.

We will also have to recursively build our dependencies' dependencies.

Most of the deps we use don't have other deps? Or at least from memory.

[Quaker762]

@z33ky I just saw this when updating. It seems eclipse has integrated Meson support, or at least the starts to it. If you've got time, I'm 110% happy for you to switch the build system over (especially since it is also compatible with VS from what I've read).