Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleanup CMake based build #1116

Closed
11 tasks done
Mizux opened this issue Mar 8, 2019 · 1 comment
Closed
11 tasks done

Cleanup CMake based build #1116

Mizux opened this issue Mar 8, 2019 · 1 comment
Assignees
Labels
Bug Build: CMake CMake based build issue Feature Request Missing Feature/Wrapper Lang: C++ Native implementation issue OS: Linux GNU/Linux OS OS: Mac MacOS OS: Windows Windows OS
Milestone

Comments

@Mizux
Copy link
Collaborator

Mizux commented Mar 8, 2019

Introduction

All CMakeLists.txt need a deep refactoring about the dependencies management.

Quick Survey

Prebuilt vs Sources

There is two main way to consume a dependency,

  1. Using some prebuilt binary

  2. Integrating the dependency source to your project and compile them along the way.

    • show stopper: CMake targets which are NOT IMPORTED must form a closure on the install export set. (see add_subdirectory() limitation below)

How to retrieve dependency Source ?

How to retrieve Prebuilt

  • Using the canonical way aka find_package() and it's the user responsibility to provide them...
  • using ExternalProject_add ("regular") to build them.
    cons: do at build time not access to project stuff e.g. config.cmake...
  • using ExternalProject_add "prebuilt hack" to compile/install deps in staging area then continue as regular find_package()
    see: https://github.com/Mizux/cmake-abseil/tree/install

Three shades of ExternalProject usage

AFAIK there is three way to use CMake ExternalProject module.

  1. "regular"
ExternalProject_Add(foo_project
  PREFIX "${CMAKE_BINARY_DIR}/dependencies/foo"
  GIT_REPOSITORY ...
  GIT_TAG "..."
  CMAKE_ARGS
    -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
  1. "submodule hack" like gtest doc
    see https://github.com/google/googletest/tree/master/googletest#incorporating-into-an-existing-cmake-project
    (ed notice the configure/build/install command set to empty string -> only the "download/update step is performed") like a git submodule (aka Strategy 2)

  2. "prebuilt hack" like "submobule hack" BUT build/install it in a staging area and add this staging to CMAKE_PREFIX_PATH
    example: https://github.com/Mizux/cmake-abseil/tree/install

Roadmap

Misc

Related PR

  • PR Feature/better find package #1019 find_package() everywhere, Tricks: you may have hidden add_subdirectory() inside FindFoo.cmake
    • nice trick since it will make the super build seen as a regular project
    • you can control what you want by CMAKE_PREFIX_PATH (i.e. find your custom FindFoo.cmake or the one in the system (good for distro maintainer))

Related issues

Reference

add_subdirectory() limitation

If you see this kind error

CMake Error: install(EXPORT "MyLibTargets" ...) includes target "MyLib" which requires target "deps" that is not in the export set.

Bravo ! you just figure out the limitation of add_subdirectory() vs regular cmake install dependencies ;)
add_subdirectory() add dependency targets not as IMPORTED targets so your export set must contains them (think of a graph closure of all target not imported) which you can't do unless hacking dependency source to modify the export set name...

note: bear in mind that until CMake 3.13, you can't add target to your super project export set.

The install(TARGETS) command learned to install targets created outside the current directory.

src: https://cmake.org/cmake/help/v3.13/release/3.13.html#commands
note: simpler example here: https://github.com/Mizux/cmake-abseil

Coin-OR integration

long story: coin-Cbc was on svn and I created the repo Mizux/cbc based on their "mono-repo" svn archive, then I added a CMake-based build.
Now, coin-OR use a one repo per library approach, you can see on github they have split coin-or in several repo, so I moved it to mizux/coinor-cbc in order to fork coinor/Cbc to add (again) a CMake-Based build.

Here the list of my fork:

Hope to soon send PR to coin-or maintainer, CMake patches/improvement are welcome !
warning: until I would consider my CMake integration "Stable/good enough" I'll heavily use rebase/fixup on my branch to keep an atomic final CMake single patch, which mean don't rely on SHA1 until release (i.e. PR is sent to coin-or)...

@Mizux Mizux added Bug OS: Windows Windows OS OS: Linux GNU/Linux OS OS: Mac MacOS Build: CMake CMake based build issue Lang: C++ Native implementation issue labels Mar 8, 2019
@Mizux Mizux added this to the v7.1 milestone Mar 8, 2019
@Mizux Mizux self-assigned this Mar 8, 2019
@Mizux Mizux added the Feature Request Missing Feature/Wrapper label Apr 5, 2019
Mizux added a commit that referenced this issue Apr 11, 2019
- By default don't build dependencies simply call find_package()
- By default only build C++ library
- IF building Python, Java or .Net wrapper then force build dependencies
  - Build dependencies as STATIC
  - Build and Install (in CMAKE_BINARY_DIR) dependencies at configure time
@Mizux
Copy link
Collaborator Author

Mizux commented Apr 17, 2019

Doc task moved to #1200

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Build: CMake CMake based build issue Feature Request Missing Feature/Wrapper Lang: C++ Native implementation issue OS: Linux GNU/Linux OS OS: Mac MacOS OS: Windows Windows OS
Projects
None yet
Development

No branches or pull requests

1 participant