Typo in my last message: All occurrences of CMAKE_INSTALL_PREFIX were meant to be CMAKE_PREFIX_PATH instead.
On Thu, Jan 19, 2017 at 2:57 PM, ardi <ardillasdelmo...@gmail.com> wrote: > Thanks a lot, Elisabeth, Domen, Guillaume, and Konstantin, > > I believe spack is the closest to what I need. However, all these > solutions (hunter, conan, spack...) have perhaps their strongest focus > in packaging, dependencies, automatic downloads, etc... while I prefer > to do all such tasks myself. I prefer to not have packages, just > download the source in the original developer provided form, untar it, > and to even build it on my own, following the developer instructions. > In other words, I want to be as little intrusive as possible, keeping > the original distribution file as is. Once it's built, then it's the > install phase what is critical, because a previous version of the > package might need to be uninstalled, or there might even be files > with equal names across different packages, as Domen pointed out. > > As I said, I think spack is the closest. However, I feel it tries to > automate too much the build. Yes, it gives you a lot of customization > options, but I'm not sure the complexity is worth the effort. > > However, I think I can follow the spack design without using spack: > Install every project on a different prefix. Then just keep on the > environment CMAKE_INSTALL_PREFIX set to a colon separated list of all > prefixes of all installed projects, and that's it. > > Uninstalling is trivial: delete the installation directory. > Keeping several versions of the same package is trivial too: just set > the currently used version in CMAKE_INSTALL_PREFIX > Updating is trivial as well: Install new version to a new prefix, and > either keep or delete the installation directory of the previous > version, and update CMAKE_INSTALL_PREFIX accordingly. > > Of course spack does all this automatically for you, but it does a lot > more, and, as I said, I'm not sure the added complexity and automation > is worth the effort. > > I think that by using this approach, I could reconsider moving to > spack in the future (I'd likely have to install all packages from > scratch if I move to spack later, but my directory hierarchy will end > up being the same, so all the work I do now -writing code and > projects- would be reusable without modification). > > Thanks a lot for all your ideas!! > > > On Thu, Jan 19, 2017 at 12:25 AM, Elizabeth A. Fischer > <elizabeth.fisc...@columbia.edu> wrote: >> Ardi, >> >> What you describe is pretty much what Spack does. I would take a look at >> it, see if it meets your needs. Chances are, at least some of the packages >> you need are already included in Spack: >> >> https://github.com/llnl/spack >> >> -- Elizabeth >> >> On Wed, Jan 18, 2017 at 12:39 PM, ardi <ardillasdelmo...@gmail.com> wrote: >>> >>> Hi, >>> >>> I want to install (on UNIX-like systems) a collection of open source >>> packages which use cmake as the build tool, but I need the >>> installation to be performed in a local directory (inside my home >>> directory), and I wish convenient updating to new versions of the >>> packages. >>> >>> I didn't arrive to a convincing solution, so any advice will be welcome. >>> >>> Here are my thoughts: >>> >>> The trivial solution is of course to directly install to a non-root >>> prefix when invoking cmake, but, however, this isn't well suited for >>> updating a previous installation of the packages (building and >>> installing a new version will only overwrite files that have the same >>> name, but it will keep old files that no longer exist in the new >>> version, cluttering the local installation directory with no longer >>> needed and mismatched files). >>> >>> A possibility would be to keep a copy of install_manifest.txt whenever >>> I install a package, and remembering to always run 'xargs rm < >>> install_manifest.txt' before installing a different version of a >>> previously installed package. >>> >>> But keeping the install_manifest.txt of each installed package (and >>> using it before updating a package) looks like a too-manual task, >>> candidate to some kind of automation. >>> >>> Another (perhaps wiser) possibility would be to use cpack for creating >>> either a RPM or DEB, and then use the corresponding package manager to >>> install the package. But this has problems too: most package managers >>> assume a / root installation directory. Also, I use several OSs: OSX, >>> Linux, and some BSDs, and I'm not sure that either the RPM nor the DEB >>> pkg managers will work flawlessly across all the OSs I use. >>> >>> What would you recommend here? >>> >>> Thanks a lot! >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake >> >> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake