Add Meson build definition

[ximion]

This adds a Meson build definition to this project, to allow projects using Meson to easily use it, and to make packaging undeaD in Linux distributions like Debian and Fedora much easier.
(Meson is already well supported in Debian, we need to have D include files installed properly, and having a pkg-config file is very useful to help other tools find the library when building)

The build can be tested by installing Meson, then running:

mkdir b && cd b
meson ..
ninja
DESTDIR=/tmp/test_install ninja install

You can learn more about Meson here: http://mesonbuild.com/

[wilzbach]

As mentioned on biod/BioD#26, I think

• it would be better to use wildcards here as undead doesn't get much love from a maintenance perspective.
• it would be awesome to check the Meson build automatically on Travis

[ximion]

Testing it with Travis would mean dropping the sudo: false flag, since we will need to pull a more recent Meson version (the ones in Trusty or Precise, which Travis supports, don't have D support). While we can do that for Meson, a newer Meson will require a newer Ninja - and with a newer Ninja we'll have to have sudo to install dependencies (in which case we could just as well go all-in and switch to building in a Xenial Docker container).

[wilzbach]

Testing it with Travis would mean dropping the sudo: false flag, since we will need to pull a more recent Meson version (the ones in Trusty or Precise, which Travis supports, don't have D support). While we can do that for Meson, a newer Meson will require a newer Ninja - and with a newer Ninja we'll have to have sudo to install dependencies (in which case we could just as well go all-in and switch to building in a Xenial Docker container).

There seems to be another way without the Docker container (I am not sure how long the provisioning on Travis takes) by directly download a newer ninja binary:

https://github.com/mesonbuild/meson/wiki/Continuous-Integration

[ximion]

I found a way to have the Meson build work without sudo or Docker in Travis :-)
This should work nicely.

[wilzbach]

Looks very nice :)

[CyberShadow]

Sorry, I don't understand this PR.

I understand that undeaD can be used as a source library without requiring any particular build tool (rdmd would work), but I see there are also makefiles and a dub.json file. So, this raises some questions:

• Who will be maintaining this file in the future? I don't think a lot of D users use the build system in question here, and every new build system added adds to the maintenance burden.
• Let's say that tomorrow someone contributes a CMake build file. The next day, another PR for another build system or package manager, and so on. Clearly we can't accept every such contribution because it would be impossible to maintain, so then how does one decide which build systems are worth supporting and which aren't?

IMHO, I think we are good the way things are. There are a few build tools/systems which are common across D projects (Make, Dub, rdmd) and supporting those is sufficient for official / semi-official projects. If there is interest in making Meson more popular for D projects, I think this is the wrong place to start; it would have to be either the top (DMD/Phobos/Druntime) or the bottom (great popularity among D users' projects). If there is desire to support more build systems, this can be done in a separate repository tracking this one, which delimits the maintenance burden according to the maintainers' interests better.

[ximion]

undeaD can be used as a source library without requiring any particular build tool

This is frowned upon by distro policy - we would need to justify doing that, which is annoying. Even static libraries are a bad thing, but due to D's ABI instability having a static lib is more justified.

Who will be maintaining this file in the future? I don't think a lot of D users use the build system in question here, and every new build system added adds to the maintenance burden.

As long as the package is in Debian, you can count on us fixing issues, since we want to have it build. In any case, except for adding new files to the meson.build file list, no other maintenance needs to be done.

Let's say that tomorrow someone contributes a CMake build file. The next day, another PR for another build system or package manager, and so on. Clearly we can't accept every such contribution because it would be impossible to maintain, so then how does one decide which build systems are worth supporting and which aren't?

If someone added cmake, we would happily use that. What we want from the build system is:

• to build a static and/or dynamic library for the D code
• install it to a system path to be found by the linker (`/usr/lib//``at Debian)
• to create a pkg-config file so other build systems and makefiles can discover the software and apply the appropriate build flags to find the include files and library
• to allow us to do a plain build without predefined build flags to have us select the compiler flags explicitly
• ideally perform a splitbuild to not kill the build slaves (less of an issue with D)
• work with GDC/LDC

If there is any one such buildsystem doing the job and providing all requirements, we are happy and don't really care which one it is (it should be packaged in Debian though ^^). The install requirements aren't even strictly necessary, but the reduce the amount of work packaging this software is for us.

So, in general I don't care about the buildsystem, if there is just any one working there, I am happy - I just find Meson to be particularly easy to work with compared to cmake+D and Automake+D.

There are a few build tools/systems which are common across D projects (Make, Dub, rdmd) and supporting those is sufficient

No. Rdmd isn't even in Debian yet, dub doesn't work for distro packaging at least until a lot of its bugs are fixed (no write to home, install missing, discover local packages and global locations, use shared libraries instead of building everything from source, etc.) and Makefiles don't provide all features unless someone adds all features manually (which is possible, but not work I want to do).

If there is interest in making Meson more popular for D projects

Nah, this is just to scratch an itch - if someone writes a cmake build definition, or any other solution, we're happy too. DMD can't be packaged in Debian (non-free) and the other interesting pieces (runtime/phobos) are in LDC and GDC which provide Automake and cmake buildscripts, so there is not much need to add another buildsystem if the existing one is sufficient.

In any case, even if you would not accept this patch, we will patch it in downstream to be able to build BioD in Debian (which is Andreas' goal here).

FTR: https://anonscm.debian.org/git/debian-med/libundead.git

[CyberShadow]

Thanks for the explanation. Could you please elaborate why the build definition needs to be in the project's source tree, and not part of the distro's package specification? For example, in the case of Arch Linux, the package build instructions (the PKGBUILD file) is expected to reside in ABS or AUR, not the project's source tree.

Also, would it be reasonable to just improve the makefiles to handle whatever's missing there for Debian packaging?

Rdmd isn't even in Debian yet

I was surprised by this. rdmd definitely needs to be packaged a lot more than, e.g., Dustmite.

[ximion]

Thanks for the explanation. Could you please elaborate why the build definition needs to be in the project's source tree, and not part of the distro's package specification?

Because it's not distro-specific. Anyone can use the Meson build file, even Fedora and Arch might want it, while a debian/rules file is generally only useful in Debian and therefore doesn't need to be shared upstream.(a PKGBUILD file is roughly equivalent to debian/rules).

Also, would it be reasonable to just improve the makefiles to handle whatever's missing there for Debian packaging?

Of course that would be an option - adding a pkg-config file is relatively easy, the biggest annoyance is usually multiarch support. But expanding the Makefiles is - at least from my perspective - much more work than adding ~50 lines of Meson build definitions.

I was surprised by this. rdmd definitely needs to be packaged a lot more than, e.g., Dustmite.

Each package has a maintenance cost, and the D team in Debian consists of only two active people. Also, nothing is using rdmd yet, the DebianMed team (which is actually packaging undeaD/BioD/Sambamba) just encountered the first one with Sambamba, and replacing rdmd was easier than taking on the cost of maintaining dlang/tools - at least for now. This might change in future.

[CyberShadow]

Because it's not distro-specific.

Understood. However, if a build system is only used in practice when building a package for one distribution, it's still effectively distro-specific :) If another distro tomorrow proposes adding a build specification for a different build system and argument that they can't use either Meson or dub/rdmd/make for reasons similar to your arguments above, we are back to the same dilemma. Granted, this is probably unlikely in this case, but I'm also interested in finding the correct solution here so that it could work as a precedent for future similar situations.

I hold the opinion that files specific to tools which are immediately useful to a single party should be maintained in a repository under that party's control. Though, of course, this is just my personal opinion and it's ultimately up to @dlang.

Since this is becoming political, pinging @andralex @WalterBright @MartinNowak to weigh in.

[ximion]

However, if a build system is only used in practice when building a package for one distribution, it's still effectively distro-specific

Since BioD is using Meson too, having it in undeaD would be kind of necessary to make their Meson builds work outside of Debian. Granted, technically Meson isn't required here but something installing a pkg-config file to the right place, but Meson is one way to achieve that.

If another distro tomorrow proposes adding a build specification for a different build system and argument that they can't use either Meson or dub/rdmd/make for reasons

Any distro shipping GNOME will have Meson, since many GNOME tools are switching to it - some developers even claimed that they will support Meson exclusively soon. I don't know any distro which doesn't have it yet.
DUB doesn't work for any distro, rdmd goes only half the way, Makefiles require more work.

If someone wants a cmake build file or extend the Makefile, do it and we can drop the Meson file. I really don't care as long as there is any one build system available which works well with distro packaging.

We can always patch stuff downstream, but especially stuff which is useful for many parties makes sense to submit back to upstream projects (like in this case).

[CyberShadow]

Since BioD is using Meson too

OK, but I see that the Meson build file was also added there by yourself, so I think it wouldn't be fair to count BioD as an additional party using Meson, as they likely wouldn't have added one from their initiative. Here is the discussion for that change: biod/BioD#26

Any distro shipping GNOME will have Meson, since many GNOME tools are switching to it

Good to know. Full disclosure, I went into this conversation biased by having never heard of it before today.

We can always patch stuff downstream,

Would you actually need to patch anything in this case, though? I understand that you would simply need to include and invoke meson.build from the distribution package's build script.

but especially stuff which is useful for many parties makes sense to submit back to upstream projects (like in this case).

I don't disagree, I just think it would be prudent for there to be evidence that the contribution is indeed immediately useful to multiple parties before accepting it into the source tree. I hope we can agree on that. I think the proper way forward is to keep this PR open until a second party will find the addition here immediately useful (but that's just my opinion).

[ximion]

OK, but I see that the Meson build file was also added there by yourself, so I think it wouldn't be fair to count BioD as an additional party using Meson, as they likely wouldn't have added one from their initiative.

Jup, but BioD initially only had a dub file which we can do nothing with at the moment, until dub is changed to work well for distros. So, in case of BioD, anyone who wants it in their distro will need to use the Meson file at time (I seriously tried to make dub work for packaging last year, and it only sort of worked with loads of hacks and ultimately writing Makefiles and Meson files for each project was by far the easier way).

Good to know. Full disclosure, I went into this conversation biased by having never heard of it before today.

I was also very skeptic, but after going to lunch with one of the Meson developers at the last GUADEC conference I was convinced (and at the time, this neatly solved the dub issues we had at Debian, and Meson upstream helped me a lot in adding support for the D language to it. So far, this is a great success :) )

I don't disagree, I just think it would be prudent for there to be evidence that the contribution is indeed immediately useful to multiple parties before accepting it into the source tree. I hope we can agree on that.

Classical henn-and-egg problem here ;-) I am not aware of other distros wanting to package undeaD (I originally asked Andreas who is doing the packaging at Debian to port BioD away from undeaD, but that is way more work than I expected and not feasible for us downstream at time - aspecially since it will break ABI and API, which is a no-go). But when it happens, they will find the Meson file helpful.

Btw, for me it's all a matter of how much effort it is to make stuff work for Debian. For GtkD for example, a pretty complete makefile existed already, so the easiest way to make that work for us was to just submit a few patches to make it follow the Debian FHS. Here, adding a Meson file was just simpler.

[CyberShadow]

I am not aware of other distros wanting to package undeaD

I think any D package being packaged by two different distros using a Meson build would work, as then that would be the precedent that this PR could follow.

[ximion]

I think any D package being packaged by two different distros using a Meson build would work, as then that would be the precedent that this PR could follow.

At least appstream-generator is built using Meson in Arch (and its dependency mustache-d is as well): https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/appstream-generator
Fedora doesn't have it since the RPM backend for asgen isn't complete.
Granted, this is my own software ^^ (but it ships a working dub file too) The only other packaged D software I am aware of are Terminix and GtkD, which use Automake and rich Makefiles respectively (with Terminix having experimental Meson support too), so in those two cases there isn't a strong need to have Meson.

[wilzbach]

Another submission: #33

[pjotrp]

As mentioned on biod/BioD#26, I think

it would be better to use wildcards here as undead doesn't get much love from a maintenance perspective.

Meson does nog allow for wild cards. It is also considered bad practice for reproducible build systems.

it would be awesome to check the Meson build automatically on Travis

I think it is done in #33.

[pjotrp]

I wonder who is still using unDead outside sambamba? Maybe I should just merge the code into our tree and be done with it. Not much of a point of having an unDead package in major distros if no one uses it.

[CyberShadow]

I wonder who is still using unDead

https://github.com/search?q=%22import+undead%22+language%3AD&type=Code

outside sambamba?

Never heard of that project before now.

Did I misunderstand the question?

[pjotrp]

Woops! I stand corrected. Code never dies, as they say. Very much unDead.

sambamba is used around the word in sequencing centers. 43K downloads on Bioconda. https://github.com/biod/sambamba

[pjotrp]

I think we can leave this out. BioD was the main driver for meson. See #33.

[ximion]

Jup - I have no interest in undeaD other than for making BioD work. Ideally, each project should just drop undeaD dependencies as soon as possible anyway.