Zork
Zork copied to clipboard
Integrate 3rd party dependency management
Feature Request: Integrate 3rd party dependency management
Let's take for example VCPKG
We could have a section inside zork.toml:
[dependencies.vcpkg]
sqlite3 = "3.40.0"
We would have to generate a vcpkg.json manifest in the out directory and run vcpkg install inside the out directory.
The packages will be installed in out/vcpkg_installed and can be integrated like this.
This would be a relatively simple addition implementation wise (probably) and would also solve the integration of test-frameworks:
[test-dependencies.vcpkg]
boost-test = "1.81.0"
Sure. This is one of the things that I have in mind for the upcoming releases.
One of the requests in Reddit was about package management. Managing dependencies for the user would be a real game-changer, without doubt.
So if you please, I would like to see an initial implementation of these.
But first...
- Do we start with concrete package managers? I mean, an entry like
deps.vcpkg, and other fordeps.conanand so on? - Or better do we offer a generic entry specifiying the package manager (if is supported), as for example, the compilers
- What about bring source code as dependencies directly from GitHub? For example, is the natural way in
CMakeof include this test framework directly from theCMakeLists.txtconfig file, and by far, would be my favourite feature to have.
What do you think?
Do we start with concrete package managers? I mean, an entry like deps.vcpkg, and other for deps.conan and so on? Or better do we offer a generic entry specifiying the package manager (if is supported), as for example, the compilers
To my judgement Conan and VCPKG are the most popular ones at the moment. Supporting those two would get us quite far for now. And even apart from that, there aren't that many C++ package managers to begin with.
We could implement support for those two in a somewhat extensible way to allow other package managers down the line.
As for the difference between specifying the package manager in the section header or directly with the dependency. I don't think many users mix package managers in the same project (at least to my judgement), so just having to specify it once in the section header seems more usable.
What about bring source code as dependencies directly from GitHub? For example, is the natural way in CMake of include this test framework directly from the CMakeLists.txt config file, and by far, would be my favourite feature to have.
That would be really nice to have, but I think that is a really hard problem. That is also one of the reasons, why vcpkg consists of a curated list of packages. Pulling a CMake project from Github and making it "just work" is really troublesome.
Because CMakeLists.txt is essentially a scripting language and not a declarative build description.
But if we are at a point, where some people use our build system, integrating zork projects from github would probably be easy, because we definitely already know how to build those.
I also wanted to start with vcpkg, as i don't have experience with conan and vcpkg seems easy to integrate
As with the other issue, no problem. I am really happy with the proposal, and I really want to see the changes
@foip what about this one? Was you able to figure out something for this proposal? I am really interested in know your opinion, and if you are able to get some time to go ahead with this one