On Tue, 2018-08-14 at 17:51 +0000, Filipe Laíns via Digitalmars-d-announce
wrote:
[…]
> 
> Yeah, Meson is a build system, not a package manager. This problem can be solved by simply creating a script that fetches and builds de dependencies. When creating a script, you might also want to compile the dependencies against the system's default D compiler. This way, you won't have any issues.

That's the battle isn't it. Should the system that builds be the system that also manages the packages for the build (cf. Dub, Cargo, Go, Mason), or should the two be kept separate (cf. CMake, Meson, SCons, Make).

The debate has been had on the D mailing lists a number of times and at great length. But in the end D, Rust, and Go are going with a single system for everything.

Building for Debian/Fedora/etc. can be seen as separate from building a project independent of platform. Whilst build-only clearly works for Debian/Fedora/etc. builds, and possibly for big corporate builds, for small projects the all-in-one approach is clearly winning the battle for hearts and minds.

[…]
> It uses 'dub describe' to find the files, this also allows us to check the compiler. Meson won't even let you try to compile the project if there's an compiler mismatch.

I am not sure how "dub describe" tells you which compiler is being used, it always says "compiler": "dmd" on my projects even though I only use ldc2 for build.

[…]
> I mean, you can do this but as you said, it's not recommended.

Certainly it is not recommended for Meson builds but I see no reason why. It is just duplicating information that is held on the filestore, and DRY is supposed to be a thing in computing. Convention over configuration really makes things a lot easier. But I guess this debate would turn into a flame war of competing prejudices, so probably best left alone.

[…]
> Dub is implemented this way for a reason. We really *shouldn't* use dynamic libraries, at least for now.

Maybe then Dub should be better able to handle shared objects. Whilst the whole static linking vs. shared objects is another topic that descends into flame wars of prejudice, the de facto standard tool should not really be taking sides in the war but should support both sides. Dub supports shared objects as dependencies, but just fails to be able to build them.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On 15/08/2018 9:31 PM, Russel Winder wrote:
> Maybe then Dub should be better able to handle shared objects. Whilst the
> whole static linking vs. shared objects is another topic that descends into
> flame wars of prejudice, the de facto standard tool should not really be
> taking sides in the war but should support both sides. Dub supports shared
> objects as dependencies, but just fails to be able to build them.

Until shared library support is actually designed and only then implemented, supporting it in dub any further is a lost cause.

On Wednesday, 15 August 2018 at 09:31:48 UTC, Russel Winder wrote:
> That's the battle isn't it. Should the system that builds be the system that also manages the packages for the build (cf. Dub, Cargo, Go, Mason), or should the two be kept separate (cf. CMake, Meson, SCons, Make).
>
> The debate has been had on the D mailing lists a number of times and at great length. But in the end D, Rust, and Go are going with a single system for everything.

This is obviously bad. Your distro has a package manager, you should use it, not create a separated language-specific one. If you are doing this locally, either but using the user's home of by installing to /usr/local, I don't think it's much of a problem. If you are implementing something like this at least do it in a way that the package managing feature is optional. I don't know if I'm being biased by being an Archlinux TU but from my perspective, it's not something we should do, at the very least globally.

> I am not sure how "dub describe" tells you which compiler is being used, it always says "compiler": "dmd" on my projects even though I only use ldc2 for build.

Weirdly enough, I can reproduce. This was working when I wrote the patch. I've opened an issue in the upstream.

On Thu, 2018-08-16 at 22:44 +0000, Filipe Laíns via Digitalmars-d-announce
wrote:
[…]

Apologies for the delay in replying to this one.

> This is obviously bad. Your distro has a package manager, you should use it, not create a separated language-specific one. If

I'm afraid you are onto a lost cause on this one. The whole JVM-based milieu, Ruby, Python, Go, D, Rust, etc. all have language specific repositories. Debian, Fedora, etc. pick and choose which bits they choose to package based on some algorithm almost, but not quite, totally unrelated to what is the latest version. Operating system package managers are providing the operating system, not the development tools and dependencies needed for software development.

Go, Rust, and indeed D, are going the route of static compilation as much because operating system dependencies can never be guaranteed, and are often wrong. It is not clear to me why Debian spend so much time packaging bits of the Go universe that no-one uses even if the dependencies are in fact used.

On the other hand, having GtkD (and GStreamerD) packaged is great since there are shared objects for use with D codes. There is nothing quite so depressing as waiting for LDC or DMD to statically link to GtkD. So static linking is not something I want. But waiting for Debian and Fedora to package things is often like Waiting for Godot. Hence "build it yourself" becomes a bit of a must.

This is not a simple situation, and every individuals positions on it is likely inconsistent and full of holes.

> you are doing this locally, either but using the user's home of by installing to /usr/local, I don't think it's much of a problem. If you are implementing something like this at least do it in a way that the package managing feature is optional. I don't know if I'm being biased by being an Archlinux TU but from my perspective, it's not something we should do, at the very least globally.

It may be that Arch stays more up to date than Debian and Fedora (because it
is less centralised and more like Homebrew/Linuxbrew, but Debian (and Fedora?)
is where the bulk of Linux programs get executed, and so is the obvious place
to develop.

> Weirdly enough, I can reproduce. This was working when I wrote the patch. I've opened an issue in the upstream.

Excellent.  I have a clone of Meson so can try stuff out on master/HEAD as needed.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk