www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Seems, almost all "mesonified" packages broken?

reply Denis Feklushkin <denis.feklushin gmail.com> writes:
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:

```meson
some_dep = declare_dependency(

dependency(s)
     include_directories: src_dir,
     dependencies: some_deps,
)
```

and:

```meson

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.
Aug 08
next sibling parent reply Denis Feklushkin <denis.feklushin gmail.com> writes:
On Sunday, 8 August 2021 at 09:06:30 UTC, Denis Feklushkin wrote:
 Hi!
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/
Aug 08
parent reply Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Sunday, 8 August 2021 at 14:15:23 UTC, Denis Feklushkin wrote:
 On Sunday, 8 August 2021 at 09:06:30 UTC, Denis Feklushkin 
 wrote:
 Hi!
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/
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.
Aug 09
parent reply Denis Feklushkin <denis.feklushin gmail.com> writes:
On Monday, 9 August 2021 at 17:27:37 UTC, Alexandru Ermicioi 
wrote:
 On Sunday, 8 August 2021 at 14:15:23 UTC, Denis Feklushkin 
 wrote:
 On Sunday, 8 August 2021 at 09:06:30 UTC, Denis Feklushkin 
 wrote:
 Hi!
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/
Would not be better to make a dub plugin that auto-generates meson build files out dub config?
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.
 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.
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.
Aug 09
parent reply Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Tuesday, 10 August 2021 at 02:48:21 UTC, Denis Feklushkin 
wrote:
 On Monday, 9 August 2021 at 17:27:37 UTC, Alexandru Ermicioi 
 wrote:
 On Sunday, 8 August 2021 at 14:15:23 UTC, Denis Feklushkin 
 wrote:
 On Sunday, 8 August 2021 at 09:06:30 UTC, Denis Feklushkin 
 wrote:
 Hi!
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/
Would not be better to make a dub plugin that auto-generates meson build files out dub config?
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.
The idea I had was, for a plugin that on deploy to package registry would then generate by default meson build files, and when fetched by dub on your local machine you'd already have everything set up for meson projects. This plugin could work also when you package your project too, although in this case it would be present in the package.
 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.
Well, I doubt every person using meson or any other build system would jump into changing stuff in libraries used in the project. The point of build systems and package managers is just to say 'I want this, and don't bother me setting every piece by myself', hence having a plugin for meson that knows how to convert dub libs at runtime to smth understandable for meson, would be (imho) far more useful, and would cover all dub libs by default. If someone though would want to 'pass special flag' then I guess he can fallback to old way of doing everything with your hands, or the plugin can itself help with parts of it as you've mentioned. Note, that I don't use meson at all, so not sure if it is possible to have plugins for dub, though if possible, then it would be imho better thing to make compared to wrapper packages. Just wanted to suggest you some ideas for consideration. Also what has gpl license have to do with meson plugin? Per my understanding it would be meson application that would use your plugin not in reverse, so you should be able to have any license you want.
Aug 10
parent reply Denis Feklushkin <denis.feklushin gmail.com> writes:
On Tuesday, 10 August 2021 at 08:08:50 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.
The idea I had was, for a plugin that on deploy to package registry would then generate by default meson build files, and when fetched by dub on your local machine you'd already have everything set up for meson projects.
I doubt the generated files will be good. Roughly, they will repeat dub capabilities, and only. We might as well just keep using dub or improve already implemented D module inside of Meson.
 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.
Well, I doubt every person using meson or any other build system would jump into changing stuff in libraries used in the project.
I am on strongly opposite opinion. Any code that you cannot change dies very quickly.
 The point of build systems and package managers is just to say 
 'I want this, and don't bother me setting every piece by 
 myself', hence having a plugin for meson that knows how to 
 convert dub libs at runtime to smth understandable for meson,
Such plugin is already implemented in Meson: https://mesonbuild.com/D.html#integrating-with-dub https://mesonbuild.com/Dependencies.html#some-notes-on-dub
 would be (imho) far more useful, and would cover all dub libs 
 by default. If someone though would want to 'pass special flag' 
 then I guess he can fallback to old way of doing everything 
 with your hands, or the plugin can itself help with parts of it 
 as you've mentioned.
Oh no! I've done it so often and a lot! But after the Meson I do not want to return to this horror.
 Note, that I don't use meson at all, so not sure if it is 
 possible to have plugins for dub, though if possible, then it 
 would be imho better thing to make compared to wrapper 
 packages. Just wanted to suggest you some ideas for 
 consideration.

 Also what has gpl license have to do with meson plugin? Per my 
 understanding it would be meson application that would use your 
 plugin not in reverse, so you should be able to have any 
 license you want.
An unfortunate analogy (https://en.wikipedia.org/wiki/Viral_license) If you have already started using a Meson, then all the dependencies are better, let them also be Meson as possible.
Aug 10
parent Denis Feklushkin <denis.feklushin gmail.com> writes:
On Tuesday, 10 August 2021 at 10:00:43 UTC, Denis Feklushkin 
wrote:

 Well, I doubt every person using meson or any other build 
 system would jump into changing stuff in libraries used in the 
 project.
I am on strongly opposite opinion. Any code that you cannot change dies very quickly.
Or, if you about internal switches and flags, this is one of two reasons to use Meson now (as for me). (Second one is cross-platform builds.)
Aug 10
prev sibling next sibling parent reply Basile.B <b2.temp gmx.com> writes:
On Sunday, 8 August 2021 at 09:06:30 UTC, Denis Feklushkin wrote:
 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!

 [...]

 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.
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.
Aug 08
parent Denis Feklushkin <denis.feklushin gmail.com> writes:
On Sunday, 8 August 2021 at 18:08:36 UTC, Basile.B wrote:

 the main problem, at least for the packages maintained by the 
 dlang-community entity, was that nobody cared about Meson
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.
 (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...
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.)
 the root dependencies worked still
I tried to use vibe.d recently - it wants to build unnnecessary libraries and reports esoteric errors about [git-redirect]
 DUB worked just fine. There's alternatively the makefiles + git
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.
Aug 08
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/8/21 5:06 AM, Denis Feklushkin wrote:
 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:
 
 ```meson
 some_dep = declare_dependency(

 dependency(s)
      include_directories: src_dir,
      dependencies: some_deps,
 )
 ```
 
 and:
 
 ```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.
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
Aug 09
parent reply Denis Feklushkin <denis.feklushin gmail.com> writes:
On Monday, 9 August 2021 at 16:31:23 UTC, Steven Schveighoffer 
wrote:

 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.
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)
Aug 09
parent Denis Feklushkin <denis.feklushin gmail.com> writes:
On Tuesday, 10 August 2021 at 02:32:34 UTC, Denis Feklushkin 
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)
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
Aug 09