[SUGGESTION] Package Management

[tex]

Big part of other modern languages is ease of using libraries via package management. I believe that important thing is that there is one package management to be used by all users of the language. Do you plan to integrate some existing C++ package management tool or to create a new one? Or do you consider current C++ state as good enough where there are lot of competing tools?

[tex]

I understand that for adoption on existing C++ project it is important to be able to use any build system that is there already.

But for any new project I am not going to use C++ only because there is no official package manager. I am going to use Rust because it is trivial to get my dependencies.

[SebastianTroy]

I find CMake with FetchContent has been making this a lot easier in C++ land recently. Also a lot of legacy code has platform dependant dependancies (that I've worked with anyway) with different names and apis per major target, is this something that rust deals with well, or at all?

[DyXel]

But for any new project I am not going to use C++ only because there is no official package manager. I am going to use Rust because it is trivial to get my dependencies.

Personally I have been using Meson for all my new C++ projects (For how powerful CMake is, I can't stand the syntax to be honest) and I have yet to find something it can't do, or a dependency it can't handle (YMMV). The good thing about it is, its also not locked to C++, you can use it for other languages as well, including Rust. I would recommend you give it a try.

I think this project is mostly concerned with the evolution of the core language, and reuse the mature ecosystem that exists already. There's also the other thing, which is standardization, there's no "official C++ compiler", there's a standard which vendors implement and conform to, at most, I could see the committee suggesting a particular implementation for a package manager, but I doubt it will ever force everyone to use a singular conforming implementation.

[helmesjo]

I'd really like to suggest having a look at build2. We migrated a large project at work from CMake + Conan to build2 and it's a vast improvement in every category. And indeed that was modern CMake with all the recommended bells and whistles.

build2 is a hierarchy of tools consisting of a general-purpose build system, package manager (for package consumption), and project manager (for project development).

[SyseAdmine]

I would like to mention

https://github.com/cps-org/cps/

and

https://github.com/cps-org/cps-config

in this regard.

More information about Common Package Specification here:

https://www.youtube.com/watch?v=s0q6s5XzIrA

and here:

https://www.youtube.com/watch?v=ZTjG8fy6Bek

[DyXel]

I feel like CPS is a good step, and in the right direction (certainly an evolution over pkg-config), but nowhere near enough a full E2E solution (which is I believe the OP is asking about).

[AbhinavK00]

cpp2 could provide a build system solution by itself, like zig.
Maybe a metafunction that enforces some build system rules, and then capitalize on existing package managers.

[DyXel]

cpp2 could provide a build system solution by itself, like zig.

This could be interesting to explore, specially because of the way meta reflection and generation needs to work, so I wouldn't rule it out as a possible evolution path for cppfront.

[helmesjo]

cpp2 could provide a build system solution by itself, like zig.

Possibly, but a build system is an enormous undertaking so I'd still recommend looking into build2 which is modern & battle tested, and already has a decent set of packages (see cppget.org). The packaging process itself is very straight forward.

Maybe a metafunction that enforces some build system rules, and then capitalize on existing package managers.

Coming from a background of cmake + conan in a large project I'd strongly discourage using the approach of (somewhat) shoehorning in other solutions in the mix. It's a can of worms IMO, and the patching required for all corner cases quickly becomes a full time job. The payoff from the build2 approach of not reusing other build systems but instead "layer" itself over the source (non-intrusively) is quickly evident, and the process itself is very straight forward (upstream as a git submodule and simply symlink the include/source dirs/files in the new project structure). See here for examples and here for the basic packaging guidelines.