Open BenMcLean opened 5 years ago
Sample implementation from Cake build system
Is this something that's still considered?
If you mean is someone working on it - no. But there's a repository of contributed tools and it could easily go there as a starting point if someone had something working they wanted to share (https://github.com/SCons/scons-contrib).
SCons hasn't to date dealt with the provisioning side, rather deferring that to the developer - set up an image with known components to get reproducible builds. SCons does this for it's own CI builds - the provisioning happens entirely outside SCons. The closest it probably gets is some contributed tools to deal with downloading an unpacking sources from external locations (tarballs, zipfiles, etc.). Any thoughts of what this would look like?
I'd like scons to be able to ingest C++ NuGet packages, which I figure would work the same way C++ NuGet packages work in Visual Studio. I believe that the NuGet pkgs are just zip files and the files that specify which NuGet packages to download are just zip files. There's nothing really all that proprietary or secret about NuGet. It isn't a build system: it's just a software package management and distribution standard. See Microsoft's documentation here and here.
It would be ideal to support both packages.config and PackageReference style NuGet includes in scons builds, if that could be a thing. Here is an example of a packages.config file from another build system that ingests NuGet.
This is a feature it is common to see in other build systems which scons is missing.
How should it work?
I believe what Visual Studio / NuGet does is take in some XML (from packages.config or the PackageReference tag in the Visual Studio project file) which has the package name and version number. Then it goes looking at the NuGet.org web site (or other specified NuGet repos) to download that version. It comes as a pkg file which is really just a zip and it gets unzipped under the /packages/ folder. The idea is that the /packages/ folder is ignored by Git and strictly off-limits for any developer to touch. Only the build system touches it. That way, if the project gets built on two different machines, both machines know exactly where to go and what version of the dependency to download and use without having to keep all the code of the dependencies in the repo. You just clone and build, and the build script automatically downloads all the dependencies and puts them in the right places.
What's the advantage of using it?
Ideally, you should be able to download and build programs from source without worrying about dependencies. When a dependency needs to be updated, the update should be only a one line change. (the version number in the XML) This makes it easier to maintain a codebase with rapidly multiple rapidly changing dependencies.