Things are not always quite that simple, but most of the time they’re close.Īt its simplest, Repoint just checks stuff out from Git or whatever for you, which doesn’t look very exciting. It’s portable and it works the same on Linux, macOS, or Windows.
#Sonic visualiser source code install
The expected deployment of Repoint consists of copying the Repoint files into the project directory, committing them along with everything else, and running Repoint from there, in the manner of a configure script - so that developers generally don’t have to install it either. But unlike npm et al, all Repoint actually does is clone from the libraries’ upstream repository URLs into a subdirectory of the project directory, just as happens with submodules, and then report accurately on their status compared with their upstream repositories later Like them, it creates a lock file to record the versions that were actually installed, which you can commit for repeatable builds. Like npm, Bundler, Composer etc., Repoint refers to a project spec file that you provide that lists the libraries you want to bring in to your project directory (and which are brought in to the project directory, not installed to a central location). I use it for projects in C++ and SML among other things. Essentially, situations where you want, or need, to be a bit hands-off from any actual package manager.
It is intended for use with languages or environments that don’t have a favoured package manager, or in situations where the dependent libraries themselves aren’t aware that they are being package-managed. Conceptually it sits somewhere between Mercurial/Git submodules and a package manager like npm.
I’ve just tagged v1.0 of Repoint, a tool for managing library source code in a development project.
0 kommentar(er)
