Autotools: migrate to Meson

[ThomasAdam]

FVWM's build system is old, and configure.ac has a lot of legacy/dead code which is no longer required.

Added to which, some of the m4 macros in use could probably be replaced with newer constructs in autotools since the time they were written some years ago.

It would be nice to audit this.

For example:

• imagepath can be set here, but is configurable via runtime, so should be removed. It's already set via fvwm/fvwm3.c...

[BrianA-MN]

Intersting thing is the ConfigFvwmDefaults also has IMAGEPATH statement for default configs which is actually already $[FVWM_USERDIR]. You can also pass to configure --with-imagepath=PATH switch. configure's IMAGEPATH information starts around L5645. configure.ac IMAGEPATH logic starts around L185.

[mikeandmore]

Would CMake be a good idea for FVWM3?

[ThomasAdam]

Would CMake be a good idea for FVWM3?

Possibly. I'm more familiar with autotools -- but if you had a good reason for us to consider CMake, I'd happily listen.

Would you be willing to help with that?

[mikeandmore]

Would CMake be a good idea for FVWM3?

Possibly. I'm more familiar with autotools -- but if you had a good reason for us to consider CMake, I'd happily listen.

Would you be willing to help with that?

I don't have a better reason, other than it's more recent.

I can help with this, but unfortunately, I'm not really familiar with autotools...

[pete4abw]

Hi @ThomasAdam . I was inspired by your Release Version Script, and created a project specifically for using git describe to update m4 variables in a configure.ac file. Currently, it will parse a tag or a release tag and return any or all components of it to configure.ac. There is an init function where all the activity occurs (excerpted here). It can, of course, be tailored to a particular project's needs. gitdescribe Project. At the end, it will merely echo a single variable. Cheers.

init() {
    # git describe raw format
    describe_tag=$(git describe $tagopt --long --abbrev=$commit_length)

    # if tag has a leading `v' this will remove
    # if some other tag format is used, change or omit
    describe_tag=${describe_tag/v/}

    # git describe prefixes commit with the letter `g'
    # this substitution removes the g. If the letter `g' is part of tag, this logic
    # will need revision, such as reversing $describe_tag and then reverting
    # echo $describe | rev, for example
    describe_tag=${describe_tag/g/}

    # assign commit, tag revision, and version to variables using `-' separator
    commit=$(echo $describe_tag | cut -d- -f3)
    tagrev=$(echo $describe_tag | cut -d- -f2)
    version=$(echo $describe_tag | cut -d- -f1)

    # set micro version or full micro version if tag revision > 0
    micro=$(echo $version | cut -d. -f3)
    [ $tagrev -gt 0 ] && micro=$micro-$tagrev-$commit

    # assign minor version
    minor=$(echo $version | cut -d. -f2)

    # assign major version
    major=$(echo $version | cut -d. -f1)
}

[ThomasAdam]

Hey @pete4abw

Oh that's cool! Thanks for letting me know! Would you consider sending a PR to fvwm3, switching out the current implementation for yours?

[pete4abw]

Hey @pete4abw

Oh that's cool! Thanks for letting me know! Would you consider sending a PR to fvwm3, switching out the current implementation for yours?

I'll take a look, @ThomasAdam. I'll clone it and see what I can contribute. You reference a lot of variables that are hard coded and I'll have to understand their use. I think we can easily set up gitdesc.sh to return each of those. The goal is not to have to hardcode in configure.ac. But thank you for turning me on to this approach. I was having a dickens of a time with m4_ifelse inside an m4_define to conditionally assign a value. For example if the revision count was 0, no need to append to the micro version. I just could not get that working. Now I just call, gitdesc.sh micro.

I'll let you know.

[ThomasAdam]

As an aide-memoir and for anyone else following this...

The wider-context changes can be found on the ta/autotools branch -- specifically the configure.scan file. It's this work which will sit alongside any changes @pete4abw can help with for release management.

If anyone wants to pick up the work on ta/autotools, do please get in touch.

[pete4abw]

A first step at #402 . Briefly, configure.ac will no longer need to be modified. Using m4_macros, and updating fvwm_version_str.sh to fetch log info using git describe and git show. The ISRELEASED variable is gone. Instead, VERSIONINFO will either be released or not released. Release dates will be filled in with the tag commit date if release tag == HEAD. In addition, the release dates will use 4 digit years do avoid confusion with month days.

RELDATELONG = 23 December 2020 RELDATENUM = 2020-12-23 RELDATESHORT = 23 Dec 2020

This is only a first step. More work needs to be done. Developer Documentation should be updated as well.

[ThomasAdam]

Hi all,

So I'm revisiting this after the latest autotools update now throwing up a tonne of warnings.

Although autoupdate helps, the configure script is really showing its age. I am not sure I want to put the effort in to keep the autotools subsystem alive, especially as there's twenty years of workarounds which themselves are likely obsolete.

Therefore, this effort will now be focused around switching to CMake. Anyone who has experience with this and wishes to help, please get in touch.

[ThomasAdam]

Meson is the only viable alternative at this point. I've started something (see: #691) -- but this will have to be after 1.0.5 now.

[ThomasAdam]

Will pick this up someday -- but unlikely to be any time soon. Closing this for now.

[polarbub]

I've been taking a crack at doing this with cmake, and I've made quite a bit of progress, but now I'm onto making the config.h generation work. There is a lot of macros in there, so I checked the code for uses of the macros and a bunch of them were unused. Many of these were macros indicating if a function or header was present. This file contains all of them that weren't used. Are these functions and headers required, so they need to be checked for and have the build fail without them or is it fine to not worry about them?

[ThomasAdam]

Hi @polarbub

That's interesting -- thanks for taking another look. To be honest, if I were to migrate away from autotools, I would prefer meson -- on balance, that tends to be the next hop from autotools. Projects such as xorg have been doing this incrementally for some time.

[polarbub]

With meson, you would still need to still need to make a config.h. Do you know which of those functions and headers are required for building the project?

[ThomasAdam]

Hi @polarbub

They'll mostly all be required. From looking though, here's the ones I know we need:

HAVE_STDARG_H
HAVE_STDIO_H
HAVE_STDLIB_H
HAVE_STRDUP
HAVE_STRFTIME
HAVE_STRING_H
HAVE_STRTOL
HAVE_SYS_SOCKET_H
HAVE_SYS_SOCKET_H
HAVE_SYS_WAIT_H
HAVE_TEXTDOMAIN
HAVE_UNISTD_H
HAVE_VFPRINTF
HAVE_XFT2
HAVE_XFT_UTF8
HAVE_XRANDR

I've checked the others in the list, and we're not using those headers.

[polarbub]

Thanks! I will switch to meson. It looks pretty close to the syntax of cmake so it shouldn't be too hard

[ThomasAdam]

Excellent, thank you, @polarbub -- if you can pull this off, that would be a huge feat indeed! It's been on my list for ages now...

One thing -- I presume you're not doing a "direct" translation from autotools -> meson -- there's a lot of very old/historical tests in the autotools buildsystem in fvwm3 which we most certainly won't need in meson.

[polarbub]

What I'm doing is copying the list of source files from the .am files and then add dependencies until it compiles. I've tried to look at acinclude.m4 and Makefile.am, but they were a bit too confusing. The two files are an old automake file and a new cmake one (it needs to be converted to meson) CMakeLists.txt Makefile.am.txt

[polarbub]

I think that a closed issue isn't a great place to talk about this. Should I make another issue or is there a better place?

[ThomasAdam]

I think that a closed issue isn't a great place to talk about this. Should I make another issue or is there a better place?

Nope. I've reopened this.

[polarbub]

What platforms are does fvwm build on? There are references to HP-UX, Solaris, Minix, VMS, and macOS just to name a few. Can I just delete these?

[ThomasAdam]

What platforms are does fvwm build on? There are references to HP-UX, Solaris, Minix, VMS, and macOS just to name a few. Can I just delete these?

Not quite. The following platforms are the ones which are known to work:

MacOS Solaris

Minix and VMS haven't been supported for years. Look at the git history, for instance.

[polarbub]

There are a few headers, libraries, and functions that are checked to be present by the old build system and are just used in the code. Is it okay to not check those and just let the build fail if the system doesn't have them?

[ThomasAdam]

Hey @polarbub

Generate a PR for what you have so far, and I'll take a look for you. 🙂

[polarbub]

I really haven't done that much. The headers, libraries, and functions that are checked and required to exist in the build system and are used in the code without checking the HAVE_ macro are in https://github.com/polarbub/fvwm3/blob/pb/meson/required_functions_headers.h . Also see pr #944

[polarbub]

Looking here it says that checking for compliant string.h is obsolete and shouldn't have to be done. Can I get rid of these checks?

[polarbub]

@ThomasAdam have you had a chance to look at that?

[ThomasAdam]

Hi @polarbub

I have now had chance to take a look. Having seen the start you made (thanks for that!), I've come up with a slight alternative. Have a look at the ta/meson branch in this repository. I wouldn't pay too much attention to the git commit history, but start with meson.build in the root of the repository, and go from there. So far, I have libfvwm3.a compiled, fvwm3 itself compiled, and a handful of modules.

So far, I'm just providing a config.h compat layer, as I don't want to change any of the #ifdef conditions in the code for the moment.

Feel free to continue where I've left things if you're still interested. A few things to consider:

• gettext -- po/ needs thinking about. How will this work with FvwmScript? Look at acinclude.m4 for inspiration.
• We need to think about the special-case some modules will have with EXTRA_DIST and to understand how meson handles that.
• --program-{prefix,suffix,transform-name} needs thinking about.
• golang "support" -- we need to detect golang to exclude building FvwmConsole

I'm not saying the meson.build file in the root of the repository is the best -- it'll need cleaning up.

[eli-schwartz]

We need to think about the special-case some modules will have with EXTRA_DIST and to understand how meson handles that.

meson dist (the equivalent of make distcheck) starts off by adding all files in the repository and then provides hooks to fine-tune this.