Hello,
at work, we have a mono-repo with multiple applications/libs (dozens).
The build phase is ok, but I'm not sure about the release process.
When we release, we release one application at a time.
(CMAKE_SKIP_INSTALL_ALL_DEPENDENCY is true)
In order to speed up releases, we always perform an incremental build.
Unfortunately, we don't have one unique release process :
process 1 :
- a Jenkins pipeline executes some automatic tests then release the
binary to production. This Jenkins pipeline only builds this single
application, then executes the install step, then packages the binary
with some auxiliary files for deployment in prod.
process 2 :
- the whole source tree is built regularly through Jenkins, then, from
another Jenkins pipeline, an install step will be performed in the
last built directory to deploy only the required application
Both process 1 and process 2 are built in our CMakeLists.txt.
Process 1 just uses regular install directives + ninja install
Pros : simple
Cons : install step can be costly
Install step can be costly because, as the build directory is not
emptied, the install step will install every single binaries left over
from a previous build that have an install rule.
Also, we have install directives for non binary files (python files
for example) which will be installed unconditionally every time.
Process 2 is not triggered through the install step but as a regular
build target. Under the hood, the build step will add a POST_BUILD
step attached to the target that will invoke "cmake -P
${CMAKE_BINARY_DIR}/cmake_install.cmake -DCOMPONENT=${component}"
Pros : more "chirurgical", only install what's required
Cons : - if an application depends on several components, we need to
describe this in cmake (dependencies are described twice : once for
the build, once for the install)
- need to maintain an extra "non standard" layer (albeit a small layer)
At this point, I'd like to ask if you see simple steps we could take
to stay as simple and standard as possible without paying the cons
(lenghty install step, double description of dependencies, extra layer
to maintain).
I have a proposal of my own, I'm just not sure this is technically
feasible. I will definitively run a POC sometime, but I thought I
would run it by you first to get your advice/experience.
So maybe the problem is we have one monolithic CMake system where all
apps are described.
What if every single application had its own independent CMake system
(while still being able to depend on common libs, that needs to be
built only once) ?
One app would describe its dependencies, the install step would then
stay simple, and only the reachable install directives would be
triggered in a per-app build.
Is it something which is feasible ? How would you implement it ? (I
thought about ExternalProject_Add but have no experience with it and
I'm not sure it would work in that case ?)
Also, we would still need to be able to build all applications in one
single command.
Do you think creating a "meta" cmake, equivalent to what we have right
now, but on top of those independent, per-app cmake, is feasible ?
(Again, I guess using ExternalProject_Add) ?
Thanks very much for your help
David
--
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:
https://cmake.org/mailman/listinfo/cmake
