Severe behavioural change regressions in release branch

[Ben Boeckel]

On Tue, Oct 28, 2014 at 09:58:58 +1300, Ben Cooksley wrote:
> If anyone is interested, help would be appreciated to get a Contracts
> style build up and running.
> In particular, pointers to documentation on how to perform such builds
> would be appreciated - we'll need to run "make install" for parts of
> it which doesn't seem to happen in any of the existing examples as far
> as I can see.

Since it's a CMake build, ExternalProject should make it fairly
straightforward. A quick sketch of the non-boilerplate code I see in the
current contracts tests:

    externalproject_add(kdelibs
      GIT_REPOSITORY [...]
      GIT_TAG        [...] # The oldest supported release.
      CMAKE_ARGS
        [...]
      INSTALL_DIR    "${CMAKE_CURRENT_BINARY_DIR}/install")
    externalproject_add(someotherkdelib
      DEPENDS        kdelibs
      GIT_REPOSITORY [...]
      GIT_TAG        [...] # The oldest supported release.
      CMAKE_ARGS
        # Might not be necessary.
        "-DCMAKE_MODULE_PATH={$CMAKE_CURRENT_BINARY_DIR}/install/lib/cmake"
        [...]
      INSTALL_DIR    "${CMAKE_CURRENT_BINARY_DIR}/install")

The rationale for using the oldest supported release is so that we make
sure whatever was written *then* still works today.

--Ben
-- 

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-developers