I just created a dub package. Frankly, the whole thign is backward.

[Egor Pugin]

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

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.