dnsdist: Install binary, man page and systemd unit files with meson

[rgacogne]

Short description

Checklist

I have:

• read the CONTRIBUTING.md document
• compiled this code
• tested this code
• included documentation (including possible behaviour changes)
• documented the code
• added or modified regression test(s)
• added or modified unit test(s)

[coveralls]

Pull Request Test Coverage Report for Build 13304780866

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall first build on ddist-meson-install at 64.727%

---

Totals
Change from base Build 13260297130:	64.7%
Covered Lines:	128305
Relevant Lines:	167189

---

💛 - Coveralls

[rgacogne]

Hmm, right, it worked locally because I already had a dnsdist.1 file, but the current meson workflow does not generate it automatically, we need to call the man-pages target explicitly. I'm not sure how to handle the installation of the man page, then, back to the drawing board.

[omoerbeek]

No immediate clue myself either, but I can take a look as well if you want.

[rgacogne]

I tried to get out of this corner by using configure_file for each man page, passing the resulting file object to install_man, but the issue is that we have a single command generate-man-pages.py, which is a wrapper for sphinx so not the source of the issue, that generates all man pages in one go. It would be a lot easier if we had one command per man page. Still looking.

[rgacogne]

I pushed a new version using custom_target instead of run_target that seems to work locally, but let's see how it goes on our CI. Note that I had to edit the man pages generation for the auth and rec as well since the man pages generation script is shared by all products.

[omoerbeek]

For dnsdist on macOS, the generation of the man pages works with the diff below (might be because of my specific python version)

diff --git a/pdns/dnsdistdist/docs/requirements.in b/pdns/dnsdistdist/docs/requirements.in
index 42b2df01f..f4779e6c8 100644
--- a/pdns/dnsdistdist/docs/requirements.in
+++ b/pdns/dnsdistdist/docs/requirements.in
@@ -12,3 +12,5 @@ docutils!=0.15,<0.18
 jinja2<3.1.0
 alabaster==0.7.13
 pbr # setup-requires for sphinxcontrib-fulltoc
+standard-pipes
+standard-imghdr
diff --git a/pdns/dnsdistdist/docs/requirements.txt b/pdns/dnsdistdist/docs/requirements.txt
index 1cfea0b89..90d0b61a7 100644
--- a/pdns/dnsdistdist/docs/requirements.txt
+++ b/pdns/dnsdistdist/docs/requirements.txt
@@ -1,5 +1,5 @@
 #
-# This file is autogenerated by pip-compile with Python 3.11
+# This file is autogenerated by pip-compile with Python 3.12
 # by the following command:
 #
 #    pip-compile --generate-hashes requirements.in
@@ -264,6 +264,14 @@ sphinxcontrib-websupport==1.2.4 \
     --hash=sha256:4edf0223a0685a7c485ae5a156b6f529ba1ee481a1417817935b20bde1956232 \
     --hash=sha256:6fc9287dfc823fe9aa432463edd6cea47fa9ebbf488d7f289b322ffcfca075c7
     # via sphinx
+standard-imghdr==3.13.0 \
+    --hash=sha256:30a1bff5465605bb496f842a6ac3cc1f2131bf3025b0da28d4877d6d4b7cc8e9 \
+    --hash=sha256:8d9c68058d882f6fc3542a8d39ef9ff94d2187dc90bd0c851e0902776b7b7a42
+    # via -r requirements.in
+standard-pipes==3.13.0 \
+    --hash=sha256:5805d0738fa17192e58cc4dea26dcfe9b8c5cd9c77e78d5dbded8bc3bda428c9 \
+    --hash=sha256:cde270ae625064211dbcd1c8f35a540b70d8ccd7443b099a496f8e6a44fed2f3
+    # via -r requirements.in
 urllib3==2.3.0 \
     --hash=sha256:1cee9ad369867bfdbbb48b7dd50374c0967a0bb7710050facf0dd6911440e3df \
     --hash=sha256:f8c5449b3cf0861679ce7e0503c7b44b5ec981bec0d1d3795a07f1ba96f0204d

But the install step says:

ERROR: File 'dnsdist.1' could not be found

./dnsdist-man-pages/dnsdist.1 exists

[rgacogne]

meson.build:574:2: ERROR: custom_target keyword argument "output" Output 'dnsdist-man-pages/dnsdist.1' must not contain a path segment.

FFS.

[omoerbeek]

meson.build:574:2: ERROR: custom_target keyword argument "output" Output 'dnsdist-man-pages/dnsdist.1' must not contain a path segment.

FFS.

Yeah, struggled with that a lot when I did meson.build for rec.

[rgacogne]

I'll sleep on it but at this point I'm no longer sure I want to move to meson.

[omoerbeek]

I'll sleep on it but at this point I'm no longer sure I want to move to meson.

A agree that the custom target stuff is ugly, but in general I'm pretty happy with meson.

[rgacogne]

I worked around the limitation for now, I think.

A agree that the custom target stuff is ugly, but in general I'm pretty happy with meson.

I still prefer meson to autotools, but right now I have the same feeling than with cxx: there is a fair amount of design choices in meson that in theory force you to do things in a clean way (great!) but often make it very hard to migrate from an existing setup.

[omoerbeek]

I see a warning on install with meson version 1.6.1:

Installing dnsdist to /opt/homebrew/bin
Installing dnsdist.1 to /opt/homebrew/share/man/man1
Installing /Users/otto/pdns/pdns/dnsdistdist/dnsdist.conf-dist to /opt/homebrew/etc
Warning: trying to copy a symlink that points to a file. This currently copies
the file by default, but will be changed in a future version of Meson to copy
the link instead.  Set follow_symlinks to true to preserve current behavior, or
false to copy the link.

[omoerbeek]

This works here (there's a warning in the dnsdist install case, see other comment). Rec and auth install targets are not complete yet, but that can be done separately.

[eli-schwartz]

The original design behind this came from the meson project lead's frustration with, IIRC, trying to debug cmake builds where a build rule in one directory created outputs in another directory, while the other directory had its own build file that had entirely different, unrelated logic. There was no mapping from the place where a target is created to where it was originally defined so it was perceived as extremely difficult to figure out what the definition of such a target even was.

There is an RFC design discussion to relax this in meson to allow subdirectories in outputs without allowing scribbling all over another build file's scope. Still need to write the code for that, though. :(

[rgacogne]

I see a warning on install with meson version 1.6.1:

Installing dnsdist to /opt/homebrew/bin
Installing dnsdist.1 to /opt/homebrew/share/man/man1
Installing /Users/otto/pdns/pdns/dnsdistdist/dnsdist.conf-dist to /opt/homebrew/etc
Warning: trying to copy a symlink that points to a file. This currently copies
the file by default, but will be changed in a future version of Meson to copy
the link instead.  Set follow_symlinks to true to preserve current behavior, or
false to copy the link.

Thanks, it should be fixed now!

[rgacogne]

The original design behind this came from the meson project lead's frustration with, IIRC, trying to debug cmake builds where a build rule in one directory created outputs in another directory, while the other directory had its own build file that had entirely different, unrelated logic. There was no mapping from the place where a target is created to where it was originally defined so it was perceived as extremely difficult to figure out what the definition of such a target even was.

There is an RFC design discussion to relax this in meson to allow subdirectories in outputs without allowing scribbling all over another build file's scope. Still need to write the code for that, though. :(

I 100% agree that this is a good rule to have, it totally makes sense for new projects. Having the ability to relax it to deal with existing design choices (bad ones, no question there, so I don't blame meson for making it difficult to keep them) would be wonderful, and if I ever find the time to look at meson's codebase I'd be happy to give it a shot.
I don't want anyone to take my previous comment, about not being sure that moving to meson is the right choice for us, as a comment against meson, because it's not. It's a thought about the number of differences between the existing build system and meson, and how difficult maintaining both of them during the necessary transition period will be.

[eli-schwartz]

You can always get it done at the "small" cost of defining the build rule itself in subdir/meson.build instead. It's not very clean if that is the only reason you'd have a meson.build file in that directory. I usually see the need for something like this when people want to expose headers which are in git as:

lib/foo.h
lib/config.h
lib/util.h

for internal use, but installed as foo/foo.h, foo/config.h, foo/util.h and that's how downstream consumers are expected to write their includes. It is thus impossible to use that as a subproject dependency fallback without somehow "installing" the headers, and that usually means creating a foo/meson.build that copies the headers into a more #include friendly structure. It would be nice if you didn't need the extra source directory just to allow the outputs to go to the right place.

The other common use case I hear about is also related to headers :) but in the form of code generators that produce structured outputs with internally-consistent includes in a free format. Protobuf etc. Meson has generator() for this but you can't install the results.