Evaluate making Zig rely on another project for package management

[mschwaig]

Package management seems to be a big topic the Zig project wants to tackle in the 0.6 release cycle.

I think it would be worthwhile to evaluate if the best way forward could be finding an existing package manager that fits nicely with Zig and making the necessary adaptations for using it with Zig.

This could be done through adding support for the Zig build system and compiler to this package management system and by making sure Zig is easy for package managers in general to interface with.

A blessed package manager that is already popular in the C/C++ world could promote code reuse, especially for cross-language dependencies.
It could be an opportunity for Zig code to gain access to already existing repositories of packaged software to depend on and even for developers in other languages to seamlessly rely on useful Zig packages as they become available.

Zig already benefits from interfacing with well established great tooling like gdb and valgrind instead of reinventing the wheel there. Sure package management is a really big and complex topic and seemingly not a well-saturated space for C/C++. Still I do believe the efforts for evaluating existing options will have an indirect payoff in lessons learned along the way even when Zig proceeds to create its own package manager.

[Cloudef]

I think zig should play nice with pkg-config. Language specific package managers are wrong way to go. (What if I want to depend on non zig package?)

Language specific package managers are ill solution for the "I just want this project to have in-source builds", when one could instead use existing package managers to install the dependencies in local directory, pointing pkg-config env var there and running make.

It's whole different can of worms in non linux/bsd environments where package management in general is non existent though, but that's not really a language's problem.

Making language heavily dependent in the package management itself is a mistake though I think, you lose lots of flexibility on how to satisfy those dependencies. At the very least, I think language-specific package management is sort of waste of effort, when it could be solved globally, by having search paths, linkage and popular package manager people want to package their stuff for (heck, I've been using pacman myself to do this for both linux and mingw builds).

[mschwaig]

One specific package manager that I think warrants a closer look is Conan:

• manages C/C++ dependencies built from source using various build systems or as binary packages
• uses Python 3 to describe packages and as its implementation language
• based on a git-inspired decentralized client-server model
• cross-platform
• MIT-licensed

Conan does not dictate one singular build system per project hierarchy. Instead it allows the user to depend on several packages built with different build systems living side by side. As I understand it the latest proposal in #943 does not cover this kind of usage.
It would be great if people did not have to touch the build system of their dependencies unless they really want to. People can be really stubborn when it comes to this kind of thing, sometimes with good reason.

[andrewrk]

I think zig should play nice with pkg-config.

This is now done if you use zig build. 29b82d2 (it made it into the 0.5.0 release)
After #2041 is resolved it'll work with -l parameters as well.

Zig package manager is planned, and won't pull in a third party dependency.

[gkdr]

I think zig should play nice with pkg-config.

After #2041 is resolved it'll work with -l parameters as well.

It seems in 0.5.0 it is possible to use -l and -L, i.e. the output of pkg-config --libs, but I cannot use the output of pkg-config --cflags. In my case, this means running it and then replacing every -I with -isystem manually since there is no alias. For multiple libraries this is a bit annoying.

Is there anything I missed that would make this additional alias a bad idea?

[daurnimator]

Is there anything I missed that would make this a bad idea?

There's lots more granular data required. e.g. many packages need different flags for linking dynamically vs statically (see e.g. --print-requires-private). You can get just the -I flags with --cflags-only-I.

[gkdr]

You can get just the -I flags with --cflags-only-I.

Okay, but there is still no alias that lets me use -I instead of -isystem. I realize I didn't word my question well, but the missing alias is what I meant to ask about.

[andrewrk]

@gkdr you're asking for a -I command line parameter? Yeah that's fine, I'll add that now.

[andrewrk]

-I command line parameter accepted as of 3af2202

[gkdr]

Yes, and thanks!