On Tuesday, May 17, 2016 at 3:54:50 PM UTC-5, Peter Dimov wrote:
On Tuesday, May 17, 2016 at 1:19:24 PM UTC-5, Peter Dimov wrote:
Paul Fultz II wrote:
Something like this:
git clone git@github.com:boostorg/hana.git mkdir build && cd build cmake ../hana/ cmake --build . cmake --build . --target check cmake --build . --target install
This builds, tests, and installs hana.
I wonder how this workflow would look like if we assume Boost layout, f.ex. from an extracted release tarball.
It should be the same., if boost supports cmake. So, boost should
Paul Fultz II wrote: provide
a top-level cmake that calls add_subdirectory for each library that has a CMakeLists.txt file. However, this can be done later.
You're talking about building the whole Boost, and that's not what I meant. I asked about the equivalent of the above, building, testing and installing Hana, but from the directory structure of a Boost distribution.
Ok, you could just do `cmake libs/hana` for the cmake step. However, this won't build hana's dependencies. Another way would be for hana to provide a target just for its test, so using `hana-check` instead of `check`: git clone git@github.com:boostorg/boost.git mkdir build && cd build cmake ../boost cmake --build . --target hana cmake --build . --target hana-check cmake --build . --target install Another option would be to do something like bpm and place the libraries and dependencies for hana in their own directory and then create a top-level cmake that calls `add_subdirectory` for each library, but I believe you were referring to the tarball release, so this doesn't really apply.