On Saturday, 23 April 2022 at 20:15:27 UTC, deadalnix wrote:

Is there some possible compromise with dub and biuld.d?

Like if biuld.d exists and has a "linux run this" comment, dub will attempt to run it; maybe define some syntax there to make it flexible.

On Saturday, 23 April 2022 at 20:15:27 UTC, deadalnix wrote:

The problem is that if we don't impose restrictions on how Dub packages can build, it's a complete Wild West from user perspective. Dub packages would install, or require you to install countless third-party build systems or even package managers, and they would likely set and read environmental variables willy-nilly.

Also unlike general purpose package managers, Dub needs to be portable to the Windows world. This is another reason you can't just have it build however it happens to work on your system.

Same goes to the version scheme. If you could have versions like "1-experimental-0", Dub would have no way to know how it's supposed to sort different versions from oldest to newest. Forcing SemVer solves that.

On Tuesday, 26 April 2022 at 11:37:51 UTC, deadalnix wrote:

You're approaching this from the wrong perspective. Dub isn't for packaging an arbitrary project as effortlessly as possible. Use rpm/apt/ports/flatpak/snap/nix/chocolatey/etc for that.

Dub is for packaging a pure D application, library or wrapper so that anyone with a D compiler can compile your D code as easily as possible. The idea is that the user does not need anything but Dub and a D compiler to build a DUB package. If you require something beyond that, you're using Dub for a purpose it's not intended to. It's more about the user and less about the packager.

On Saturday, 7 May 2022 at 20:58:54 UTC, Dukc wrote:

Hi,

I see this thread is discussing package management/buils systems.
I have some experience in this area in C++ and will do some notes.

1. Declarative artificial build descriptions

See https://github.com/cppan
'specs' repo contains many examples, but they are serialized and not very useful as is (replace all '\n' with '\n' in 'cppan' field).
You can check this build script with cmake inserions -https://github.com/cppan/cppan/blob/v1/cppan.yml
Cmake was used as a driver here.

Declarative approach showed itself unuseful in complex cases (C libs, C programs with complex build systems).
Relying on other tools also is a dependency, also very dangerous.

2. Plugin-based compiled build descriptions

Second (and existing) approach is compiled C++ code into shared object plugins.

https://software-network.org/
https://github.com/SoftwareNetwork
https://github.com/SoftwareNetwork/sw (main repo)
https://github.com/SoftwareNetwork/specifications (storage of specs, specs are visible on the website also)

Imperative approach and C++ itself give more space when describing builds, but there are limitations also.
Compilation can be quick with PCH (implemented and used) and probably with C++20 modules (not yet implemented).
Linking of these plugins take visible amount of time and a lot of RAM. So, parallel builds of these plugins are slow on small systems.

In general I see following problems with this approach.
We get now full tree of any build. How do we store build settings? We must be able to tweak any parameter, any definition, and compile/link option in any of downstream libs.
I used simple object-based config tree like json/yaml and this is the problem.
With such approach flexibility is the problem, we cannot pass custom data structures as config to plugins and order to use them.

Some scalability is present, but not great because of some bad implementation decisions.
Low or very low flexibility. It is hard to ask dependencyA to build with option X.

You can check the website, some application is possible, but still it is not that smooth.
Project have some integrations with cmake. Build capabilities as make/ninja.

3. [WIP] Next iteration, current ideas

Build description of a project should be compiled into an executable binary that contains whole build tree config.
Every target(package) must have its build config in the form of polymorphic object so it can change any property directly, not in any json/yaml/xml-like tree structure.

Not giving more details here because they are still only in form of ideas.

Ending

I see some mentions or preferences of some people for p.1. or p.2.
But curious readers may try to repeat steps 1 or 2 get their own experience which takes couple of years or point what was done wrong in their opinion.

Quick comments about some existing high level C++ tools (build systems (BS), build system generators (BSG) and package managers (PM)).

cmake - BSG; very bad DSL; not viable in long term?
meson - BSG; better because of python-like DSL. But bad because not imperative, not real Python (very bad - look at their parser). Questionable system of project settings. Need more practical work on their PM.
premake - BSG; Lua. Lua is fine.
conan - PM; python dsl is good, but it's hard to work with every underlying BS projects have.
vcpkg - PM; what DSL? still no package versions? There was some work. Are package versions ready? Many decisions are questionable also. Project is pushed with MS power, has a lot of users.
xmake - BS+BSG+PM; Lua as build desc; looks good, no deps on BS/PM, needs evaluation. Lua is fine.
make - BS; just works. Easy for simple configs, harder for large and huge projects. P.3 future projects must aim for its simplicity in describing simple builds.
ninja - BS; works. What about dynamic build graphs (Fortran/C++ modules)?
presented here
cppan - BSGG: yaml->cmake; cmake is bad, building something on the top of it is worse.
sw - BS+BSG+PM; C++ as build desc; complex native plugins building; low flexibility on huge build graphs.
other langs
D(dub,...?) - do not know much. You should tell better.
rust(cargo) - BS(?)+PM(?); smooth integration, does it job.
java(...) - established set of tools; ecosystem is fine.
C#(...) - powered by MS.

Not implementing BS+BSG+PM combo is bad.
You will get dependency on make/ninja/PM etc.
Viable project must do everything itself.

On Saturday, 7 May 2022 at 21:36:40 UTC, Egor Pugin wrote:

What do you think about using conda as a package manager? It's completely decoupled from build systems(as well as which programming language you use, from what I can tell)

On Saturday, 7 May 2022 at 20:31:00 UTC, Dukc wrote:

Yes, I think this makes sense. If it is true that Dub can generate cmake builds then it means that Dub packages can later be converted to other package managers that does not use Dub. If this actually is possible with Dub today or could be made possible, in a transparent way, then that would be a very important quality to obtain/retain.

On Sunday, 8 May 2022 at 03:47:41 UTC, Tejas wrote:

Looks like just binary package manager.
I do not see how it helps building software.
It can make an environment for you, but how to integrate it into cmake or make a build file for make/ninja?

On Sunday, 8 May 2022 at 09:24:18 UTC, Egor Pugin wrote:

Yeah, that's actually what I like about it: it's completely seperate from any build system and programming language

Over here, you can see how people don't like dub, and would like to use something else while still managing to provide packages to the community as a whole

I'd reckon that people build their code using whatever software they prefer, but publish their code on conda for easy usage, allowing the flexibility of their preferred tool, while maintaining the easy accessibility of their package.