[CMake] Managing a local installation of cmake-built open source packages

[ardi]

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 <ardillasdelmonte at 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.fischer at 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 <ardillasdelmonte at 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
>>
>>