Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Meson #608

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

Add Meson #608

wants to merge 1 commit into from

Conversation

meator
Copy link
Contributor

@meator meator commented Dec 7, 2024

I do not expect this PR to be merged. As I understand it, XBPS is not under active development. Features & bugfixes are accepted when they are needed, active development of features is not the focus of XBPS. The current configure system works, so I don't think this PR will be merged.

I have discussed my intention of introducing Meson to XBPS in #xbps some time ago.

I wanted to take a look at the internals of XBPS. I wanted to begin at the build system level to become familiar with XBPS's structure. This PR is a result of that. I also wanted to review the current build system. I have found #598 thanks to this. I have found additional issues while revisiting this now, but they are too inconsequential to make a PR for them.

I also find Meson more practical to work with both as an user and as a developer. Out of the box compile_commands.json support, ccache enabled by default, easy management of sanitizers etc. can be useful for development. Having an alternative build system can be an useful resource when debugging certain issues.

Pros:

  • out-of-source builds
  • simpler syntax
  • ease of use
  • 50% faster than current system (but configure time is negligible for both)
  • nice compile_commands.json support
  • [RFC] Add internationalization to XBPS #350 is easy to adapt to this PR
  • more "correct" in certain areas than current system (uninstall target isn't broken, flag & feature checking is done through Meson's functions, which are more robust, some feature checks are better)
  • dependencies can be resolved through Meson's Wrap system
  • Meson's verbose output, error messages and logfiles are miles ahead of the current system

Cons:

  • this PR requires Meson >=1.3.0 (it shouldn't be that hard to support an earlier version though)

@meator
Copy link
Contributor Author

meator commented Dec 8, 2024

As stated above, I don't think that this PR has much of a future. But if there is interest in introducing Meson to XBPS or if this could be discussed further, I'd be willing to continue working on it. This PR is production ready (except for missing tests and git revisions which both require modifying files).

Fully static XBPS builds can be set up like this under Musl:

LDFLAGS=-static meson setup build -Dprefer_static=true --force-fallback-for=zlib -Ddefault_library=static -Dprefix=/usr

-Werror is dropped, because Meson's werror is more strict than configure
one.

This implementation does not support running tests. The Kyua testsuite
heavily relies on in-source builds. Tests would have to be rewritten
(at least the Kyuafile files, but probably more) to support Meson.

Meson does not support retrieving git info and providing it as a
compiler flag. Meson's vcs_tag() mechanism supports outputting to
a (header or source) file only. This would mean that xbps.h.in would
have to be modified.

No substitution is done on xbps.h.in. See void-linux#598 for explanation.

_DEFAULT_SOURCE is dropped, because _GNU_SOURCE implies _DEFAULT_SOURCE.

-D_FILE_OFFSET_BITS=64 is set automatically by Meson.

Work in progress!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant