Hi!

Previously I seen meson.build files in some of popular and frequently used packages (mir-core, vibe, etc.)

Now I tried to compile some of my packages with Meson build system and this is almost impossible!

meson.build files contains constructions like:

some_dep = declare_dependency(
    link_with: some_lib, # IMHO, library should be created from dependency(s)
    include_directories: src_dir,
    dependencies: some_deps,
)

and:

pkgc = import('pkgconfig') # Why we need this if we moving to pure Meson?
pkgc.generate(...)

Perhaps I do not understand Meson spirit, but it seems that all these files are poisoned and it is easier to write them from scratch than to fix them.

On Sunday, 8 August 2021 at 09:06:30 UTC, Denis Feklushkin wrote:

Also I propose to everyone interested in Meson join into team on Github and create Meson wraps/forks for all needed packages: https://github.com/D-meson/

On Sunday, 8 August 2021 at 09:06:30 UTC, Denis Feklushkin wrote:

the main problem, at least for the packages maintained by the dlang-community entity, was that nobody cared about Meson (there was no dedidcated PR for example) excepted when the CI stopped working, which happened some times to times. So people forgot to update the version numbers... the root dependencies worked still but the last time a call to action was posted on the forums the reality is that the tools probably didn't successfully build since monthes.

Now there's a particular error that was made when Mir-core was added as dependency of the experimental allocators package, which I would qualify more as a time-bomb rather than as a poisoning, but soon or later something else would have broke everything as, again, nobody cared about the Meson recipes.

DUB worked just fine. There's alternatively the makefiles + git submodules but that was less boring to maintain, as when a dub dependency number had to be changed people just had to pull the matching submodule to he matching git tag.

On Sunday, 8 August 2021 at 18:08:36 UTC, Basile.B wrote:

This case solvable by Meson "patching" capability, with it we can maintain our own additional meson.build files outside from official repository.

After release of new version of package it will be need only replace link/branch/tag inside of .wrap file in most cases.

Yep, and we can do this too.

(Or we can just ignore versions at all: SemVer is good for distribution packages, but I think SemVer concept for software dependencies failed - minor changes often break compatibility. This is a separate issue.)

I tried to use vibe.d recently - it wants to build unnnecessary libraries and reports esoteric errors about [git-redirect]

But makefiles isn't alternative to Meson: if community has made almost non-usable Meson scripts (Meson specially designed as Turing-incomplete language!), then, in my opinion, any makefile larger than 100 lines quickly turns into a disaster.

On 8/8/21 5:06 AM, Denis Feklushkin wrote:

some_dep = declare_dependency(
     link_with: some_lib, # IMHO, library should be created from dependency(s)
     include_directories: src_dir,
     dependencies: some_deps,
)

pkgc = import('pkgconfig') # Why we need this if we moving to pure Meson?
pkgc.generate(...)

I can say from experience, someone came into my projects (std.io and iopipe) and proposed meson build files. I didn't understand it, but I incorporated it.

The one thing I can't stand about it (and it makes me want to just discontinue support) is that meson requires manual updating of version numbers in the build file.

I forget frequently to update that number, so then it breaks. Not using it, I don't really want to deal with that kind of headache.

-Steve

On Sunday, 8 August 2021 at 14:15:23 UTC, Denis Feklushkin wrote:

Would not be better to make a dub plugin that auto-generates meson build files out dub config?

Having this in dub, it would be possible to then auto generate for all packages meson build files.

A meson plugin for dub config would also work.

Best regards,
Alexandru.

On Monday, 9 August 2021 at 16:31:23 UTC, Steven Schveighoffer wrote:

Just remove "version" from project(...) - version (revision) can be established by .wrap file at user side (user must refer to a specific source revision - this will be version in dub terms)

On Monday, 9 August 2021 at 17:27:37 UTC, Alexandru Ermicioi wrote:

As I understand, dub plugin system generates only for particular config what selected for current build. But meson.build files should cover all dub abilities simultaneously.

Here is unfinished CLI tool what uses dub as library and tries to convert whole dub script:
https://github.com/denizzzka/dub2meson/

It already can help to create skeleton of meson.build (it is boring to add all of these sources manually for mature projects)

This tool will not be prefect after finishing - Meson is more flexible whan dub, mechanic dub->meson conversion will give us not very quality meson.build files from point of view of Meson-envolved persons.

For very simple projects only, because used by this way packages will not be able use Meson. For example, you won't be able to pass from Meson some tricky flag to some object file. Meson as a GNU license, it is pretty viral.

On Tuesday, 10 August 2021 at 02:32:34 UTC, Denis Feklushkin wrote:

Wrong idea: Meson versions isn't work by this way

Solution is near of here:

version: which is a free form string describing the version of this project. You can access the value in your Meson build files with meson.project_version(). Since 0.57.0 this can also be a File object pointing to a file that contains exactly one line of text.

So, it is need to set up some hook to git