Buildsystem Overhaul

[p01arst0rm]

no idea how to chat with any maintainers, so ill drop this here

i've successfully gotten tomahawk to build & run using a replacement meson build system to replace the quirky weird cmake. bunch of other small fixes that have improved stability too, (or at least as far as i can tell)

tests have not been migrated yet, nor CI stuff. still a lot of work to do, but getting there.

after the new buildsystem is fixed ima look into getting the plugins to actually be not hard coded

[dschmidt]

tomahawk on Freenode is the place to chat with us.

Especially find muesli, hugo and me (domme) there.

I'm very familiar with CMake and not at all with Meson. I know that our CMake code is pretty rusty, but I would prefer overhauling that (or even starting that from scratch) than switching to Meson.

What hardcoded plugins are you talking about?

[hugolm84]

no idea how to chat with any maintainers, so ill drop this here

i've successfully gotten tomahawk to build & run using a replacement meson build system to replace the quirky weird cmake. bunch of other small fixes that have improved stability too, (or at least as far as i can tell)

tests have not been migrated yet, nor CI stuff. still a lot of work to do, but getting there.

after the new buildsystem is fixed ima look into getting the plugins to actually be not hard coded

Hi @p01arst0rm and thanks for your interest in contributing to Tomahawk!

As I understand it, you have already made changes to the build system and fixed some issues in the current code base, great!

If you want to make changes and have them merged upstream, I would suggest that you first create an issue where we can discuss the particular problem, then create separate PR's so that they can be reviewed, tested and merged easier.

Setting personal preferences aside, what actual benefit does meson provide over CMake for Tomahawk as a project? Granted, the CMake code is a bit dated and should be updated to a more modern take, but your argument to change because of "quirkiness" is not compelling to me. To make such a big change, possibly requiring everyone maintaining and contributing to the project to learn a new build system, I think you need to be more expressive in what the positive net effect is.

What problems are you facing exactly?

/Best

[p01arst0rm]

the main issues i see are

• difficulty in reading CMake (its never really clear what is happening, and you have to sit down and think about it before you understand). slows down development time quite a bit imo

• relative paths in header files.. never a brilliant idea

• missing #define declarations to header files because it assumes that it has them included, when its not the case

• define to a header in abcd.h then a repeat #define right after in abcd.cpp. not really a problem but can be confusing when trying to track down exactly just where bad code is being added in

• bunch of buffer overflows littered all around the project

• libportfwd is missing definitions in a header file which is probably not helping

• CMake doesn't have the ability to check pkgconfig for dependencies. meson does. it will also check the CMake cache, and can even do a direct search for a library, header, or function by querying the compiler. allows for far simpler and neater code whilst also massively improving the user experience ("grr wtf i just installed that dependency, what do you mean it doesn't exist!!!?")

• meson is provably faster than other buildsystems at compilation when given an equal scenario. sometimes the difference is small, sometimes massive

• meson allows for the setup of cross compilation, i believe this will allow cross compiling to the windows binary within a non NT environment without all the hassle it currently requires

[hugolm84]

@p01arst0rm

As I said in previous comment, changing the build system due to a personal preference of readability and clarity of another system is not compelling enough.

I'd like to keep the issues separated and only discuss build system issues in this thread.

Relative paths is not an issue with CMake it self. CMake supports PkgConfig. CMake supports cross compiling. CMake can generate ninja project files just like meson, which should make no difference for compilation times.

Until persuaded otherwise, my current standpoint is that the best way forward would be to update the current CMake files to adhere to a modern CMake approach.

For unrelated to build system issues, like buffer overflows, missing defines or general improvements, I suggest that you create separate PR's. We will happily review and merge!

[p01arst0rm]

cmake "supports" pkg config. in theory it works but in practice its very tempremental.

the source changes will come with the buildystem change as i see no real benefit to me personally to maintain two buildsystems for no reason just to upstream merge...

[dschmidt]

the main issues i see are

• difficulty in reading CMake (its never really clear what is happening, and you have to sit down and think about it before you understand). slows down development time quite a bit imo

Well, I'm certain that there are lots of wtfs per minute for Tomahawk's CMake codebase, but that's certainly not inherent to CMake itself. CMake has evolved and it's certainly possible to create a readable and meaningful CMake buildsystem. Just the same as with any other system, being able to read and create something new with it doesn't come without knowing at least the basics.

• relative paths in header files.. never a brilliant idea

It's not that simple. Rather than saying "this is never brilliant", why don't you say, why you think it's bad and we can discuss that. There are pros and cons.

• missing #define declarations to header files because it assumes that it has them included, when its not the case

Again what are you suggesting instead? Using -D all over the place? Again there are pros and cons. Please suggest something concrete.

• define to a header in abcd.h then a repeat #define right after in abcd.cpp. not really a problem but can be confusing when trying to track down exactly just where bad code is being added in

I don't get what you are talking about.

• bunch of buffer overflows littered all around the project

What has this to do with CMake vs meson?

• libportfwd is missing definitions in a header file which is probably not helping

What has this to do with CMake vs meson? And what is the actual issue?

• CMake doesn't have the ability to check pkgconfig for dependencies. meson does.

As you stated on later you know this is not true.

it will also check the CMake cache, and can even do a direct search for a library, header, or function by querying the compiler. allows for far simpler and neater code whilst also massively improving the user experience ("grr wtf i just installed that dependency, what do you mean it doesn't exist!!!?")

CMake can obviously all of this too.

• meson is provably faster than other buildsystems at compilation when given an equal scenario. sometimes the difference is small, sometimes massive

CMake is pretty fast too and as @hugolm84 already said it can generate ninja files as well, doubtful there are differences justifying to learn a new buildsystem.

• meson allows for the setup of cross compilation, i believe this will allow cross compiling to the windows binary within a non NT environment without all the hassle it currently requires

I'm starting to get the impression you hate CMake for the pure lack of knowledge. CMake handles cross-compilation just fine. In fact we've been cross-compiling Tomahawk for Windows from the beginning on.

[dschmidt]

Because of rude behavior here, in #675 and on IRC I don't expect any follow up here.