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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021