flatpak-builder
flatpak-builder copied to clipboard
flatpak
Port to meson
So I started a meson port, which compiles and runs fine. But before I proceed to finish completely the port I have a few questions first.
- Would a meson port be acceptable?
- Should I drop the autotools buildsystem to avoid having them deviate in quality as time passes?
- The main reason I want to port flatpak-builder to meson is because I'd like to make flatpak-builder available too as a library that GNOME Builder could use to avoid all the duplication that happens between both codebases. That could be done with autotools, but I really don't want nor know how to write autoconf stuff. That would allow GNOME Builder to do a more fine grained treatment on the modules and sources of a manifest, like updating modules A, B, and E but not all modules, as we've been willing to do in https://gitlab.gnome.org/GNOME/gnome-builder/-/merge_requests/355, without having to expand flatpak-builder's CLI for every single feature Builder would need. There wouldn't be any need for a very strict API stability since only a narrow set of projects would actually use this library (though I don't see any reason for breaking the current API which is already very nice IMO).
If 3. is not something acceptable then I won't finish the port since well… my interest in porting to meson is in using flatpak-builder as library in GNOME Builder.
Depends on https://gitlab.gnome.org/GNOME/libglnx/-/merge_requests/23 getting fixed/merged (in the meantime deleting the content of glnx-missing-syscall.h makes it build alright).
There's a few FIXMEs or TODOs in the code~~but in general the biggest things left to port are tests/ and doc/.~~ Done.
Can one of the admins verify this patch? I understand the following commands:
-
bot, add author to whitelist -
bot, test pull request -
bot, test pull request once
For reference the discussion on porting Flatpak to meson was here: https://github.com/flatpak/flatpak/issues/2241
However perhaps it's fine for flatpak-builder to be ported to meson before Flatpak.
Should I drop the autotools buildsystem to avoid having them deviate in quality as time passes?
Yes I think so, or if there's a reason to keep it add a CI check to ensure it's maintained.
For reference the discussion on porting Flatpak to meson was here: flatpak/flatpak#2241 However perhaps it's fine for flatpak-builder to be ported to meson before Flatpak.
There's also https://github.com/flatpak/flatpak/pull/4141 related to this topic. If there's a need to support e.g. rhel7, then I guess the meson requirement could be lowered by not using newer features. But then, albeit running flatpak apps is important even for older systems, building flatpak apps on such systems seems a bit less important and common.
Should I drop the autotools buildsystem to avoid having them deviate in quality as time passes?
Yes I think so, or if there's a reason to keep it add a CI check to ensure it's maintained.
Yeah, I don't think it makes sense to keep both I agree.
Thanks for commenting! :)
So I just pushed a new revision, that includes support for building the docbook documentation and manual pages, and the tests. I also pushed the changes for the resolved threads. I didn't fix the last opened thread to wait until the other MR is merged to rebase on top of it.
Some few things left to do later are to drop the autotools buildsystem, and update the CI file to use meson.
@smcv: WDYT of 3. in my bullet list in the first message? Does that sounds reasonable to you?
Also, there's some hacks and things that doesn't quite work yet but I've added FIXMEs for input.
WDYT of 3. in my bullet list in the first message? Does that sounds reasonable to you?
Sorry, I don't think I'm the right person to say whether providing a library API from flatpak-builder is desirable.
So I just pushed a new revision, that includes support for building the docbook documentation and manual pages, and the tests. I also pushed the changes for the resolved threads. I didn't fix the last opened thread to wait until the other MR is merged to rebase on top of it.
Some few things left to do later are to drop the autotools buildsystem, and update the CI file to use meson.
@smcv: WDYT of
3.in my bullet list in the first message? Does that sounds reasonable to you?
I don't think this is a good idea. That implies there being a stable API. It would probably be better than some other project would provide this API and flatpak-builder and GNOME Builder would both consume it. flatpak the project is one well-maintained projec with maintenance branches which would be a good obvious pick for hosting a common API for building flapaks.
I'm picking up this branch, will polish it a little, and push the improvements here. Hope you're all okay with this.
Yes I'm fine with that. Thanks for picking it up :) I personally went as far as motivation goes, so it's nice to see someone picking it up and bringing a more bareable buildsystem to flatpak-builder.
Tests are technically in TAP format, but Meson's TAP parser is unhappy with the test scripts, even though they're fine. Don't set the 'tap' protocol for tests for now (but still run them).
As witnessed in this CI run: https://github.com/flatpak/flatpak-builder/actions/runs/3342041605/jobs/5533854367
I took a look at this. The error in question was removed in Meson 0.63.0 via commit https://github.com/mesonbuild/meson/commit/a7e458effadbc884eacf34528df3a57b60e43fe3
However, the error is really just saying your TAP output stream is NOT in fact in a valid format. You have unknown result lines that cannot be parsed as TAP:
- parsers must not treat it as a failing test, but ignore it or convey it as a distinct status to the harness
- some harnesses then ignore it, some warn about it, some error about it. Some changed their approach.
Output from e.g. programs being run to implement the test, is supposed to be wrapped in # prefixes to indicate to TAP that they are tests.
I think Meson should just warn about it, not ignore it. So I submitted a PR: https://github.com/mesonbuild/meson/pull/10964
Note that historically it was an error, for one release it was a silent pass, and now I want it to be a pass, but message you to tell you not to do that. For portability reasons and to avoid only supporting Meson >=0.63.0 you want to use properly compliant TAP anyway...
Could be worth adding a .gitattributes file with this line https://github.com/hse-project/hse/blob/master/.gitattributes#L10
Thanks everyone for their contributions.
AFAICT the only remaining thing missing is installed-tests: https://github.com/flatpak/flatpak-builder/issues/528
Patches and testing welcomed :)
