Re: [CMake] Need ideas/opinions on third party library management

For what it's worth, what I've done here is to create binary packages of each third-party library for each supported platform (i.e. .deb packages for Ubuntu, .rpm packages for RHEL/CentOS, Chocolatey packages for Windows). Except for cases where the system already provided sufficient versions

Re: [CMake] Need ideas/opinions on third party library management

On 13-Aug-16 03:12, Elizabeth A. Fischer wrote: I don't think CMake is the best place to do it, for a number of reasons. I would not try to re-invent the wheel here. Can you provide any details? I personally think that CMake is a natural and the only place where it should be done. On

Re: [CMake] Need ideas/opinions on third party library management

On Fri, Aug 12, 2016 at 4:58 PM, Roger Leigh wrote: > You can simplify this to two steps: > > 1. Clone the superbuild repository > 2. Build the third-party and first-party packages > > This is the approach we take with the OME super-build >

Re: [CMake] Need ideas/opinions on third party library management

Wow I actually completely forgot about that lol. I think I was looking into it for some other reasons, not related to work. I will have to look into it again. I don't really remember much about it. Thanks for the reminder. On Sat, Aug 13, 2016 at 7:02 PM, Ruslan Baratov

Re: [CMake] Need ideas/opinions on third party library management

Hi, Robert According to your GitHub account you've send a trivial patch about a year ago to the Hunter (https://github.com/ruslo/hunter) package manager. So I wonder what is your experience, have you tried it? Have you run into some troubles? Thanks, Ruslo On 12-Aug-16 22:59, Robert Dailey

Re: [CMake] Need ideas/opinions on third party library management

I would look into Anaconda, which does work for Windows. Its version management is not as well developed as Spack, but it's more cross-platform. Auto-builders are just coming into their own, it's a brave new world. I expect things to be more complete in a few years. -- Elizabeth On Sat, Aug

Re: [CMake] Need ideas/opinions on third party library management

I did some brief digging into spack, and it doesn't look like it supports Windows. All I see are shell scripts and the documentation uses POSIX. If I'm going to use a package manager, it needs to be able to support Android (ARM), Windows, and Linux. I have specific toolchains that I'll need the

Re: [CMake] Need ideas/opinions on third party library management

> > This is what Spack and other meta builders do. I don't think CMake is the > best place to do it, for a number of reasons. I would not try to re-invent > the wheel here. > See http://github. com/llnl/spack > -- Elizabeth -- Powered by www.kitware.com Please keep messages on-topic and

Re: [CMake] Need ideas/opinions on third party library management

On 12/08/2016 19:59, Robert Dailey wrote: Hello, I've been thinking of a different approach for a while. I've done some toying around with the "Super Build" concept, where I have a separate CMake project that does nothing but use the ExternalProject module to build libraries in real time

Re: [CMake] Need ideas/opinions on third party library management

This is what Spack and other meta builders do. See http://github. com/llnl/spack On Aug 12, 2016 3:59 PM, "Robert Dailey" wrote: > Hello, > > There is an internal C++ product at the company I work for which I > have written a series of CMake scripts for. This project

Re: [CMake] Need ideas/opinions on third party library management

A superbuild will work, and you can write your own Find*.cmake so that find_package works - you don't need most of what the real Find_package would do for you because you already know what is installed where as you control that. But, can you live with the trade off: long build times? What my