Meson build broken with the extraction of vibe-core

[ellie-idb]

As of current, the only way to depend on vibe (via Meson) is through this ugly hack:

mir_linux = dependency('mir-linux-kernel', method: 'dub')
eventcore = dependency('eventcore', method: 'dub')
stdx_allocator = dependency('stdx-allocator', method: 'dub')
diet_ng = dependency('diet-ng', method: 'dub')
tagged_algebraic = dependency('taggedalgebraic', method: 'dub')
vibe_core = dependency('vibe-core', method: 'dub')
vibe_core_deps = [vibe_core, mir_linux, stdx_allocator, eventcore, diet_ng, tagged_algebraic]
vibe_http = dependency('vibe-d:http', method: 'dub')
vibe_stream = dependency('vibe-d:stream', method: 'dub')
vibe_web = dependency('vibe-d:web', method: 'dub')
vibe_textfilter = dependency('vibe-d:textfilter', method: 'dub')
vibe_utils = dependency('vibe-d:utils', method: 'dub')
vibe_inet = dependency('vibe-d:inet', method: 'dub')
vibe_crypto = dependency('vibe-d:crypto', method: 'dub')
vibe_tls = dependency('vibe-d:tls', method: 'dub')
vibe_data = dependency('vibe-d:data', method: 'dub')
vibe_mail = dependency('vibe-d:mail', method: 'dub')
vibe_vibe = dependency('vibe-d', method: 'dub')
vibe_mongo = dependency('vibe-d:mongodb', method: 'dub')
vibe_redis = dependency('vibe-d:redis', method: 'dub')
vibe_dbs = [vibe_mongo, vibe_redis]
vibe_project = vibe_core_deps + [vibe_stream, vibe_textfilter, vibe_utils, vibe_inet, vibe_crypto, vibe_data, vibe_http, vibe_web, vibe_tls, vibe_vibe, vibe_mail] + vibe_dbs

Are there any plans to fix this? I've tried to approach this on a fork, but I run into several issues with fixing up the meson build:

• the modules (i.e. vibe-d:inet, vibe-d:mail) cannot be separated into subprojects (since Meson requires a separate sub-project directory)
• subdirs do not work (since vibe-core has been extracted)

and other nits:

• the meson build keeps openssl as a project-wide dependency, when only vibe-d:utils depends on it
• same goes with eventcore

I'd love to approach to fix this, as I'm looking to use vibe.d within a personal project of mine. Any pointers on where to start?

[Geod24]

Is the issue still here ? I was under the impression that Meson was used by a few users, and thus working relatively well.
I know nothing about it myself, any chance we can get your insight @Cogitri ?

[Cogitri]

Sure, I can take a look at it later today 👍

[Cogitri]

Seems like meson is borked on master:

The Meson build system
Version: 0.56.2
Source dir: /var/home/rasmus/Downloads/vibe.d
Build dir: /var/home/rasmus/Downloads/vibe.d/build
Build type: native build
Project name: Vibe.d
Project version: 0.9.4
D compiler for the host machine: ldc2 (llvm 1.25.0 "LDC - the LLVM D compiler (1.25.0):")
D linker for the host machine: ldc2 ld.gold 2.35.1-41
Host machine cpu family: x86_64
Host machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (1.7.3)
Run-time dependency zlib found: YES 1.2.11
Run-time dependency libcrypto found: YES 1.1.1k
Run-time dependency libssl found: YES 1.1.1k
Run-time dependency libevent found: YES 2.1.12-stable
Found CMake: /usr/bin/cmake (3.19.7)
Run-time dependency diet found: NO (tried pkgconfig and cmake)
Looking for a fallback subproject for the dependency diet
Cloning into 'diet'...
remote: Enumerating objects: 1130, done.
remote: Counting objects: 100% (7/7), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 1130 (delta 0), reused 3 (delta 0), pack-reused 1123
Receiving objects: 100% (1130/1130), 293.75 KiB | 658.00 KiB/s, done.
Resolving deltas: 100% (587/587), done.

|Executing subproject diet method meson 
|
|Project name: Diet-NG
|Project version: 1.7.4
|D compiler for the host machine: ldc2 (llvm 1.25.0 "LDC - the LLVM D compiler (1.25.0):")
|D linker for the host machine: ldc2 ld.gold 2.35.1-41
|Build targets in project: 2
|Subproject diet finished.

Dependency diet from subproject lib/subprojects/diet found: YES 1.7.4
Run-time dependency stdx-allocator found: NO (tried pkgconfig and cmake)
Looking for a fallback subproject for the dependency stdx-allocator
Cloning into 'allocator'...
remote: Enumerating objects: 388, done.
remote: Total 388 (delta 0), reused 0 (delta 0), pack-reused 388
Receiving objects: 100% (388/388), 170.25 KiB | 484.00 KiB/s, done.
Resolving deltas: 100% (221/221), done.

|Executing subproject stdx-allocator method meson 
|
|Project name: stdx-allocator
|Project version: 3.0.1
|D compiler for the host machine: ldc2 (llvm 1.25.0 "LDC - the LLVM D compiler (1.25.0):")
|D linker for the host machine: ldc2 ld.gold 2.35.1-41
|Run-time dependency mir-core found: NO (tried pkgconfig and cmake)
|Looking for a fallback subproject for the dependency mir-core
|Using lib/subprojects/allocator/subprojects/mir-core.wrap
Cloning into 'mir-core'...
remote: Enumerating objects: 1063, done.
remote: Counting objects: 100% (288/288), done.
remote: Compressing objects: 100% (146/146), done.
remote: Total 1063 (delta 156), reused 204 (delta 92), pack-reused 775
Receiving objects: 100% (1063/1063), 403.60 KiB | 345.00 KiB/s, done.
Resolving deltas: 100% (607/607), done.
|
||Executing subproject mir-core method meson 
||
||Project name: mir-core
||Project version: 1.1.1
||D compiler for the host machine: ldc2 (llvm 1.25.0 "LDC - the LLVM D compiler (1.25.0):")
||D linker for the host machine: ldc2 ld.gold 2.35.1-41
||Build targets in project: 3
||Subproject mir-core finished.
|
|Dependency mir-core from subproject lib/subprojects/mir-core found: YES 1.1.1
|Build targets in project: 5
|Subproject stdx-allocator finished.

Dependency stdx-allocator from subproject lib/subprojects/allocator found: YES 3.0.1
Message: Fetching OpenSSL D bindings from Github...
Message: Using non-system OpenSSL D bindings.
Message: Fetching LibEvent bindings from Github...
Message: Using non-system LibEvent D bindings.

utils/meson.build:35:0: ERROR: File vibe/internal/win32.d does not exist.

A full log can be found at /var/home/rasmus/Downloads/vibe.d/build/meson-logs/meson-log.txt

[Geod24]

@Cogitri : Thanks for testing! Do you think we could set up a CI so it stops breaking ?
I'd be happy to merge any PR in that direction, or if you don't have time, is there any example we could follow ?
Having it as its own workflow would be best, just like we currently test Musl in vibe-core.

[Cogitri]

I suppose we'd have to first add meson build to vibe-core, add it as subproject to vibe.d and fixup the source file arrays (where we list all .d files)

[HenkKalkwater]

I have made an attempt to add meson support in vibe-core, in the linked pull request above, but unit tests kept failing and I hadn't the time to fix it back then. I should be able to look at it once again today, so hopefully I can get vibe-d/vibe-core#254 ready for merge.