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 13, 2016 at 7:00 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote: > 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 package manager to use for each of these platforms, > assuming it compiles these libraries. It also needs to be capable of > cross-compiling (in the case of ARM toolchain in the Android NDK). > > I mean, we can't really call it "reinventing the wheel" if my > requirements are so specific that no current tooling can support it. > If you have any info on spack related to my requirements please let me > know. It looks promising, but so far doesn't seem like it will work > out. > > On Fri, Aug 12, 2016 at 3:41 PM, Elizabeth A. Fischer > <elizabeth.fisc...@columbia.edu> wrote: > > This is what Spack and other meta builders do. See http://github. > > com/llnl/spack > > > > On Aug 12, 2016 3:59 PM, "Robert Dailey" <rcdailey.li...@gmail.com> > 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 actually has > >> dependencies on several open source libraries, such as boost, > >> freetype, openssl, etc. > >> > >> Right now what we do is build each of these third party libraries *by > >> hand*, once for every platform we support (Windows, Linux x86, Android > >> NDK). Then we stuff the includes (headers) and libraries > >> (static/shared) in a submodule and the primary code base's CMake > >> scripts pull them in as interface targets. > >> > >> This works well and is light-weight but is a pain when upgrading or > >> changing libraries. It's a pain because if I want to upgrade boost, I > >> have to build it up to 6 times (once for each platform and once for > >> each configuration). > >> > >> 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 along with our project. So the order of > >> operations would be as follows (for our automated build server): > >> > >> 1. Clone our "Third Party" repository > >> 2. Use CMake to generate & build the "Super Build" project (this > >> builds boost, openssl, freetype, etc for the current platform). > >> 3. Clone the main code base's repository > >> 4. Use CMake to generate & build, using find_package() to refer to > >> interface targets exported by those third party libraries built in > >> step 2 > >> > >> Obviously this will make builds take significantly longer, because > >> we're constantly rebuilding the same third party libraries over and > >> over again. However, it virtually eliminates the maintenance burden > >> for third party libraries because they are built inherently with > >> everything else. > >> > >> Note that I can't refer to pre-built libraries in our build > >> environments because we need very specific control over the versions > >> of our libraries as well as the toolchains that were used to build > >> them. Also we may specifically build our libraries a certain way (such > >> as boost). For this reason we do not rely on our external environment > >> or external package managers to fulfill third party dependencies, like > >> most open source projects do on Linux for example. > >> > >> Does this "Super Build" approach sound like a better idea? What other > >> options are available? The downside with the "Super Build" solution is > >> that it will become very difficult to make the transition between > >> building third party and building our code base seamless. I can't do > >> both in the same generate step because find_package() can't be called > >> until the libraries are built & installed. > >> -- > >> > >> 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