@keszybz, could you have a look at this, please?

I really like this switch. But please, if we do the switch, remove the old configure script and Makefiles, maintaining two build systems is a nightmare.

I really like this switch. But please, if we do the switch, remove the old configure script and Makefiles, maintaining two build systems is a nightmare.

My initial plan was to make a release that still supports both build systems, but contains a deprecation warning, and remove autotools support right after the release. This would allow downstreams ample time to prepare for migration. Do you think this approach is overcautious and we should rather do the switch right away?

This would allow downstreams ample time to prepare for migration. Do you think this approach is overcautious and we should rather do the switch right away?

I don't really see a need to prepare migration, in the end all distributions should meanwhile have packages using meson, so it's just replacing configure & make with the corresponding meson files.
But I'm fine if we keep configure for one more release and remove it only afterwards.
May fear is that we end like util-linux: configure and meson with the big problem that they are never in sync and both have their own problems and bugs.

For what it's worth, as a Fedora maintainer I'm fine with just providing meson and changing the build system for a release. It's a big change that I think will pay off in the medium/long term.

Well, if nobody sees any benefits in keeping autotools support for the next release, I'm fine with dropping it before the release.

I'm trying to build our pam packages currently with meson and this PR. We build two packages: a very small one and a full features one.

I see the following error:

[   10s] Run-time dependency libsystemd found: NO (tried pkgconfig)
[   10s] 
[   10s] meson.build:307:13: ERROR: Dependency "libsystemd" not found, tried pkgconfig

I have to explicit disable logind. But that is defined as "auto", so shouldn't meson skip libsystemd dependency if it does not find it?
If I disable logind with "-Dlogind=disabled", it works.

Similar for pam_userdb:
meson.build:332:15: ERROR: C shared or static library 'db' not found
pam_userdb is "auto", but we get an error if the required libdb is not found. Disabling pam_userdb also solves this.
Same for "nis" and libnsl and "docs" and the dependencies.

It's irritating that you need to look at the meson.build script to find out which option you need to disable if you don't want a dependency.

BTW, I get this:

[34/362] Generating doc/specs/parse_y.[ch] with a custom command
../doc/specs/parse_y.y: warning: 2 shift/reduce conflicts [-Wconflicts-sr]
../doc/specs/parse_y.y: warning: 8 reduce/reduce conflicts [-Wconflicts-rr]
../doc/specs/parse_y.y: note: rerun with option '-Wcounterexamples' to generate conflict counterexamples
../doc/specs/parse_y.y:97.3-123.1: warning: rule useless in parser due to conflicts [-Wother]
   97 | | doc stuff RIGHT stuff RIGHT stuff NEWLINE {
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Maybe this is related to bison version? (I have bison-3.8.2-7.fc40.x86_64 here.)

There are missing options which we used with configure:

• --htmldir
• --pdfdir

I'm trying to build our pam packages currently with meson and this PR. We build two packages: a very small one and a full features one.

I see the following error:

[   10s] Run-time dependency libsystemd found: NO (tried pkgconfig)
[   10s] 
[   10s] meson.build:307:13: ERROR: Dependency "libsystemd" not found, tried pkgconfig

I have to explicit disable logind. But that is defined as "auto", so shouldn't meson skip libsystemd dependency if it does not find it? If I disable logind with "-Dlogind=disabled", it works.

I didn't expect this behavior. I definitely tested this, and I get the following instead without any errors:

Run-time dependency libsystemd found: NO (tried pkgconfig and cmake)

I expect that

option('logind', type: 'feature', value: 'auto',
       description: 'logind support in pam_issue and pam_timestamp')
...
libsystemd = dependency('libsystemd', version: '>= 254', required: get_option('logind'))

would make libsystemd dependency optional. I wonder why it doesn't work this way on your side.

This is meson 1.5.1.

@keszybz, any ideas why this check would behave so differently?

There are missing options which we used with configure:

* `--htmldir`

* `--pdfdir`

Indeed, these are provided by autoconf. Added.

I'm trying to build our pam packages currently with meson and this PR. We build two packages: a very small one and a full features one.
I see the following error:

[   10s] Run-time dependency libsystemd found: NO (tried pkgconfig)
[   10s] 
[   10s] meson.build:307:13: ERROR: Dependency "libsystemd" not found, tried pkgconfig

I have to explicit disable logind. But that is defined as "auto", so shouldn't meson skip libsystemd dependency if it does not find it? If I disable logind with "-Dlogind=disabled", it works.

I didn't expect this behavior. I definitely tested this, and I get the following instead without any errors:

Run-time dependency libsystemd found: NO (tried pkgconfig and cmake)

This (no libsystemd, no error) also happens in github CI.

The cc.find_library() calls are missing "required=false" as argument. From meson documentation:
If set true, Meson will abort with an error if the library could not be found. Otherwise, Meson will continue and the found method of the returned object will return false.
default = true
No idea why it works for you, it should not if cc.find_library() get's called according to the documentation. Adding "required=false" fixes it for me.

The cc.find_library() calls are missing "required=false" as argument.

Indeed, but this affects only the pam_userdb case. The use of crypt library doesn't seem to be optional because it's used unconditionally by pam_pwhistory, and other libraries are not looked up using cc.find_library().

Of course not all find_library() calls require "required: false" as argument. Some have it already (like 'util'), other don't need it, but the three ones in the userdb case are missing it.

This (no libsystemd, no error) also happens in github CI.

According to the meson documentation the libsystemd check is correct and should work. But I see the error on all systems with meson 1.3.1 and 1.5.1. Need to try to debug that later...

Between, I updated our PAM package with this PR and adjusted the spec file, this was really simple.
So for me, the current state is good enough to get merged.

This (no libsystemd, no error) also happens in github CI.

According to the meson documentation the libsystemd check is correct and should work. But I see the error on all systems with meson 1.3.1 and 1.5.1. Need to try to debug that later...

Found it, ignore it. It's a "feature" of our build system.
So the PR is now fine with the pam_userdb find_library fixes.

The only remaining issue I'm aware of is what do we do with the make releasedocs concept.

The idea of distributing pre-built documentation became flawed when we started to use profile-docbook.xsl to generate parametrized manual pages.
Now, distributing anything pre-built wouldn't play well with the meson model of placing everything it builds into a separate build directory tree.

All that goes slightly beyond the scope of this PR, but should be decided upon before the final removal of autotools build support.

Well, if nobody sees any benefits in keeping autotools support for the next release, I'm fine with dropping it before the release.

OK, I've submitted a PR that drops autotools support for the next release: #839.