3 ms·
> How else would you add/manage external dependencies for your project? Either using a package manager, or doing it "manually" (like you suggest) – a process
by gspr 5y ago
> How else would you add/manage external dependencies for your project?
Either using a package manager, or doing it "manually" (like you suggest) – a process which can of course also be automated outside of the build system.
> Do you manually install them on your local host? That's not reproducible and doesn't support multiple versions for different projects.
Of course that's reproducible and supports multiple versions. Any build system worth its salt can be directed to look for dependencies at specific locations. Then multiple versions of things can be installed at multiple locations. This is literally how things have been done for ages.
> Do you manually copy all the external deps into your own project repo, and then manually keep them updated with the latest changes?
I abhor bundling dependencies, so I'm probably not the right person to ask, but supposing that you do want to bundle dependencies: yes (a process that can be scripted just as easily as it can be handed off to the build system!)
- Joker_vD 5y agoWhy do I want the package manager to fetch and install dependencies for a project? I don't want to put all kinds of random junk into my /usr/lib before running "make" in the project's directory stops failing. And I've seen makefiles with "sudo apt install libqt5core libxml2-dev ..." in them and I didn't like that.
- gspr 5y ago> Why do I want the package manager to fetch and install dependencies for a project? You don't have to do that. If you separate the task of building from the task of managing software, you can mix and match solutions for each separate task as you wish. > And I've seen makefiles with "sudo apt install libqt5core libxml2-dev ..." in them and I didn't like that. That's obviously terrible too.
- howinteresting 5y agoBuild systems that manage dependencies are that automation you're talking about, except they're easy-to-reuse across many projects. That's incredibly valuable. Being able to ship software, especially across many platforms is much more important than maintaining some sort of purist separation between build system and package manager. Your view of affairs, after being dominant for decades, is finally receding into the background, and the world is a better place for it.
- gspr 5y agoWe shall see. The separation of concerns is of far greater value than just purism. It can ease cross-compilation, it can help building in offline environments, it can make dependency customization far easier, it can make swapping out compilers much easier, etc. These are all things that have been valuable in the past, and there's little reason to think that they aren't still valuable and will be valuable in the future.
- howinteresting 5y agocargo supports all of the things you talked about, though. Cross-compiles are part of the fundamental model of cargo (target vs host dependencies). cargo can be used in a completely offline manner easily, through either caching dependencies in an online step or vendoring them (or just not using dependencies). Cargo has pretty good support for dependency patching. The compiler can be swapped out through an environment variable, RUSTC_WRAPPER. I agree that all of those things are valuable! The cargo developers think so too which is why cargo supports all of them. I suspect the future is more in making tools like cargo support all the use cases people are concerned about, than trying to find an orthogonality where one doesn't exist.