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

Meson Build: #996

Open
wants to merge 7 commits into
base: main
Choose a base branch
from
Open

Meson Build: #996

wants to merge 7 commits into from

Conversation

Kangie
Copy link
Contributor

@Kangie Kangie commented Apr 5, 2024

  • What does this PR do?

This PR is an attempt at finishing off the WIP meson build infrastructure so that we I 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:

  • We also don't currently check the golang version. This is probably simply accomplished by calling an external script, I just haven't been bothered - golang 1.14 is 'old' in golang terms, and the build itself should error descriptively if golang is too old. (Any guinea pigs?)

See #89

@Kangie
Copy link
Contributor Author

Kangie commented Apr 5, 2024

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.

@ThomasAdam
Copy link
Member

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.

bin/FvwmPrompt/meson.build Show resolved Hide resolved
bin/FvwmPrompt/meson.build Outdated Show resolved Hide resolved
bin/FvwmPrompt/meson.build Outdated Show resolved Hide resolved
bin/FvwmPrompt/meson.build Show resolved Hide resolved
@Kangie Kangie force-pushed the mj/meson branch 4 times, most recently from 42ce867 to bd4147d Compare April 5, 2024 14:44
@Kangie
Copy link
Contributor Author

Kangie commented Apr 5, 2024

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.

@Kangie
Copy link
Contributor Author

Kangie commented Apr 5, 2024

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?

@ThomasAdam
Copy link
Member

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 main, it isn't replacing autotools at all -- I know there's plenty of platforms out there which can't use meson, but for which people still compile fvwm -- so I want to really assess that before any official switchover is considered, where it's replacing autotools.

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 Kangie force-pushed the mj/meson branch 16 times, most recently from f81aea9 to 6f4bc8f Compare April 6, 2024 11:18
@Kangie
Copy link
Contributor Author

Kangie commented Apr 6, 2024

I was out for most of today, but made decent progress this evening:

  • Docs now generate and install
    • There are a few asciidoc errors now, might seek some guidance on that as I haven't touched the source files and I'm pretty sure that they were already being processed in the same way.
  • default-config now installs

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:

[5/193] Generating doc/fvwm3styles.html with a custom command
asciidoctor: ERROR: fvwm3styles.adoc: line 7: include file not found: /data/development/temp/fvwm3/doc/fvwm3_styles.ad
[6/193] Generating doc/fvwm3commands.html with a custom command
asciidoctor: ERROR: fvwm3commands.adoc: line 7: include file not found: /data/development/temp/fvwm3/doc/fvwm3_commands.ad
[29/193] Generating doc/fvwm3menus.html with a custom command
asciidoctor: ERROR: fvwm3menus.adoc: line 7: include file not found: /data/development/temp/fvwm3/doc/fvwm3_menus.ad
[55/193] Generating doc/fvwm3styles.1 with a custom command
asciidoctor: ERROR: fvwm3styles.adoc: line 7: include file not found: /data/development/temp/fvwm3/doc/fvwm3_styles.ad

@Kangie Kangie force-pushed the mj/meson branch 5 times, most recently from 1a24514 to 3a935f0 Compare August 22, 2024 14:55
@Kangie Kangie force-pushed the mj/meson branch 11 times, most recently from 6acc82c to 55eb28a Compare September 16, 2024 09:38
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>
Prior to this change the "without PNG" build path does not successfully
build under Meson.

Signed-off-by: Matt Jolly <kangie@gentoo.org>
@Kangie Kangie force-pushed the mj/meson branch 6 times, most recently from 45d26b2 to 0ccc5d4 Compare September 18, 2024 12:12
Kangie and others added 4 commits September 19, 2024 07:46
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

Co-authored-by: Thomas Adam <thomas@fvwm.org>
Signed-off-by: Matt Jolly <kangie@gentoo.org>
For years, we've been setting FVWM_COLORSET_PRIVATE=1, so there
is no need for the include guards.
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>
Discuss new Meson build path and how to build things.

Co-authored-by: Thomas Adam <thomas@fvwm.org>
Signed-off-by: Matt Jolly <Kangie@gentoo.org>
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.

3 participants