mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #387] Thoughts on cmake? #307
Labels
No labels
HiDPI
bounty
bsd/freebsd
bsd/openbsd
bug
bug
build-infra
cantfix
critical
doc
duplicate
enhancement
fix-available
from git
from release
good first issue
help wanted
installer/package
invalid
linux
macOS
meta
needs testing
pull-request
query
question
regression
regression
v2.4.0
windows
wontfix
work-in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/barrier#307
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
@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.
@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.
@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.
@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!