[GH-ISSUE #387] Thoughts on cmake? #307

Closed
opened 2026-05-05 06:00:08 -06:00 by gitea-mirror · 4 comments
Owner

Originally created by @shymega on GitHub (Aug 4, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/387

I've been discussing this with @AdrianKoshka on IRC, but I wanted to ask the Barrier maintainers as a whole: what are your thoughts on CMake as the current build system? Would you be open to a PR using a different, cleaner build system, such as Meson and Ninja?

I do recognise however that such a change would be a huge amount of work, but in terms of breakages, as long as we merge the new changes into master, after updating CI, build scripts for the supported OSes, and the Flatpak+Snap packages. That should mitigate such breaking changes.

I'm happy to take a look and submit a PR; I've been playing with the idea locally in a test branch.

Originally created by @shymega on GitHub (Aug 4, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/387 I've been discussing this with @AdrianKoshka on IRC, but I wanted to ask the Barrier maintainers as a whole: what are your thoughts on CMake as the current build system? Would you be open to a PR using a different, cleaner build system, such as Meson and Ninja? I do recognise however that such a change would be a huge amount of work, but in terms of breakages, as long as we merge the new changes into `master`, _after_ updating CI, build scripts for the supported OSes, and the Flatpak+Snap packages. That *should* mitigate such breaking changes. I'm happy to take a look and submit a PR; I've been playing with the idea locally in a test branch.
gitea-mirror 2026-05-05 06:00:08 -06:00
Author
Owner

@noisyshape commented on GitHub (Aug 6, 2019):

The CMake scripts aren't touched often but that may be because they're a mess. If it will make someone's life easier, I'm all for something like Meson.

<!-- gh-comment-id:518485054 --> @noisyshape commented on GitHub (Aug 6, 2019): The CMake scripts aren't touched often but that may be because they're a mess. If it will make someone's life easier, I'm all for something like Meson.
Author
Owner

@shymega commented on GitHub (Aug 6, 2019):

The CMake files are heavily integrated into the project as well. With regards to Ninja, CMake can use that as a build engine.

<!-- gh-comment-id:518734340 --> @shymega commented on GitHub (Aug 6, 2019): The CMake files are heavily integrated into the project as well. With regards to Ninja, CMake _can_ use that as a build engine.
Author
Owner

@p12tic commented on GitHub (Aug 6, 2019):

Is there clear, demonstrable benefit of moving towards another build system? Any code change has risk of producing bugs, so there needs to be a good reason to justify it.

I believe that CMake fits its purpose well. It's is well supported and very popular in both open-source and proprietary worlds, which means that most potential contributors will already be familiar with it. Additionally, it seems to me that there's little evidence of CMake slowing the development team down, as the build code has relatively low churn anyway -- only around 100 lines of changes in the past 1.5 years.

I think that it's better to spend the time actually improving Barrier itself.

<!-- gh-comment-id:518838506 --> @p12tic commented on GitHub (Aug 6, 2019): Is there clear, demonstrable benefit of moving towards another build system? Any code change has risk of producing bugs, so there needs to be a good reason to justify it. I believe that CMake fits its purpose well. It's is well supported and very popular in both open-source and proprietary worlds, which means that most potential contributors will already be familiar with it. Additionally, it seems to me that there's little evidence of CMake slowing the development team down, as the build code has relatively low churn anyway -- only around 100 lines of changes in the past 1.5 years. I think that it's better to spend the time actually improving Barrier itself.
Author
Owner

@shymega commented on GitHub (Aug 9, 2019):

I've decided to close this issue given the varied feedback it received, and I feel, upon reflection, that we should stick with CMake - but that's my personal opinion.

Thank you all for your thoughts!

<!-- gh-comment-id:519968010 --> @shymega commented on GitHub (Aug 9, 2019): I've decided to close this issue given the varied feedback it received, and I feel, upon reflection, that we should stick with CMake - but that's my personal opinion. Thank you all for your thoughts!
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/barrier#307
No description provided.