Build: Support Meson #996
Build: Support Meson #996
Conversation
|
Fwiw it builds, links, and installs... On my dev machine. I have not tried a build container yet. it is also entirely untested, and I don't know the codebase well enough to be sure that everything is covered. I figure good enough for comment now though. |
|
Thanks, @Kangie Please just focus on the necessary changes to make meson build with the codebase in the state that it is in. I'm well aware of the time.h vs says/time.h issue, and the whole RETSIGTYPE return stuff, but I don't want those sorts of changes coming in as part of this work. This change is big enough without those cleanups. We can do all of that sort of thing later. |
Kangie
force-pushed
the
mj/meson
branch
4 times, most recently
from
42ce867 to
bd4147d
Compare
|
I've moved the commits to the end for now - I'm happy to make a new branch with those commits that I can PR from afterwards, but they're all fixes that IMO could easily fall under the topic of build system modernisation. As it stands none of the refactor commits materially impact on the autotools build path, we're just configuring for things that no longer exist in code. Edit: I'm happy to tidy up my commit history down to one or two atomic meson build commits (plus the refactors, etc elsewhere), just let me know what you want that to look like. |
|
In terms of further tidyup, etc, we do a lot of checks for POSIX headers, etc. Do you want to retain those or can I start stripping that down? |
|
Hi @Kangie Thanks again for looking at this. I think I'd want to do this in stages. The first approach is to get meson working side-by-side with autotools. When this is eventually merged to What I will say, is that replacement isn't going to remove anything about autotools from the build system -- if someone wishes to use autotools, they can. So to your question, any cleanups we do have to work for both autotools and meson -- things like RETSIGTYPE and sys/time.h are easy. But we're not at that point yet. There's a slew of crap from me on the meson branch your PR is based from that deliberately needs squashing together and reworking into decent commits. Additionally, I'm not sure I've made proper use of meson_options and their 'auto' field, compared with the checks I'm doing in the main/top-level meson.build file -- that really does need looking at as well. |
Kangie
force-pushed
the
mj/meson
branch
16 times, most recently
from
f81aea9 to
6f4bc8f
Compare
|
I was out for most of today, but made decent progress this evening:
It looks like there are still a number of outstanding modules. I can add them but thought I'd check if there was a reason that they weren't ported other than the WIP nature of the branch I picked up. :) asciidoc: |
Kangie
force-pushed
the
mj/meson
branch
9 times, most recently
from
55344ad to
966076d
Compare
Kangie
force-pushed
the
mj/meson
branch
8 times, most recently
from
28d9785 to
daf2501
Compare
Kangie
force-pushed
the
mj/meson
branch
2 times, most recently
from
d3c09ea to
fb80c60
Compare
Signed-off-by: Matt Jolly <kangie@gentoo.org>
- `sys/select.h` for `fd_set` - FvwmConsole: `libs/defaults` for `FVWMCONSOLE_CONNECTION_TO_SECS` - `limits.h` for INT_MAX - `time.h` for `time()`; `difftime()` - `libs/log.h` for `fvwm_debug` Signed-off-by: Matt Jolly <kangie@gentoo.org>
- png: Wrap `png_get_color_type` for Fpng - svg: Fix build with SVG disabled Prior to this commit builds without PNG or SVG could not be run successfully under Meson. Co-authored-by: Thomas Adam <thomas@fvwm.org> Signed-off-by: Matt Jolly <kangie@gentoo.org>
The intent of this commit is to provide a working meson build that implementation that is as close to the existing autotools build as is reasonable. Autotools should be considered deprecated; followup commits that modernise the codebase (e.g `time.h` vs `sys/time.h`) may include changes to autotools, and bugs will be fixed, however no enhancements to the autotools build will be made. Porting notes: FwvmPrompt: We use a script that calls 'find' to generate a list of sources to feed to golang in a custom target as there is not currently direct support for golang in Meson. bin/: Configured scripts are manually set to 'rwxr-xr-x'. drop -Wno-implicit-int: Modern compilers complain about this for a reason; we should not mask this. I can't find any current occurrances in the codebase and this will catch any future instances before they are merged. po: - Set GETTEXT_PACKAGE (mandatory for i18n module) - Add POTFILES to define files which need to be scanned for strings to translate See: - https://mesonbuild.com/Localisation.html - https://mesonbuild.com/i18n-module.html#i18n-module PRIVATE_COLORSET: always assume this is true For years, we've been setting FVWM_COLORSET_PRIVATE=1, so there is no need for the include guards. ci: We now include a Meson build that uses Clang + lld as the build system to catch bugs and warnings that our traditional autotools + GCC builds might miss. We no longer build a docker image, instead we directly execute the fvwm3-build container as a GitHub Action. GH Actions have been factored out into a common set, and are used as a matrix set to apply to Ubuntu (glibc) and Alpine (musl). The Go version in fvwm3-build has been updated to enable use with meson and eliminate the need for a complex envvar setup and invocation, however older golang is still supported (>=1.14); we're just relying on users to tell us if something is broken. While the issue with LTO builds has been resolved in this PR, it was incidental and the introduced changes will catch LTO errors before they make it into a release. Closes: fvwmorg#1056 Co-authored-by: Thomas Adam <thomas@fvwm.org> Signed-off-by: Matt Jolly <Kangie@gentoo.org>
ThomasAdam
added
type:new-feature
This PR is an attempt at finishing off the WIP meson build infrastructure so that
weI never have to think about autotools again.This includes some (very basic) fvwmprompt/fvwmconsole paths based on golang detection. This will probably need to be amended (or just dropped to simplify the build, retaining only the 'modern' path).
Known issues:
See #89