Aleksandr Kutsan "Managing Dependencies in C++"

Managing Dependenciesin C++
Kutsan Aleksandr
2020-11-26

2www.luxoft.com
Problems in life
 From time to time I can see gtest gmock sources in
projects, weird.
 Many times I totally don’t understand dependencies of
the project when I start working with it.
 Building project on another environment or cross-
compilation becomes painful.
 After some system changes project in not compliable
or works in correctly.

3www.luxoft.com
Presentation Manual
Dependencies types
Corporate Deck
Compile time dependencies
Need to be installed to developer workstation,
CI/CD server.
Required for building applications.
Compile and runtime
dependencies
*-dev libraries and header need to be installed on
developer workstation and CI/CD servers.
Required for building applications.
Library also required for application runtime.
Usually a shared library.
Only runtime dependencies
Usually IPC services like Dbus, vsomeip,
rabbitmq.
In case if application is some kind of a
framework/extension/plugin, runtime
dependency can be the pluggable application.

4www.luxoft.com
Compile time dependencies
management approaches
 Store dependencies sources within application
sources
 Fetch dependencies sources before compilation
 Use pre-installed dependencies on the system
 Fetch dependencies binaries before compilation

5www.luxoft.com
Store dependencies sources near the application sources
 You should take care about fetching security patches of the dependencies.
 Dependencies may have their dependencies.
 A lot of code to store.
 Code of the dependency is now your code, and you should take care of it.
 You can be sure that you have all assets for program compilation.
 Don’t need internet to compile a program.
 Compilation takes extremely long time.
 Dependencies is part of the program, but developers would not like to recompile it even after a clean build. Need to create a
separate compile target that will install dependencies.
 Bad idea to install dependencies to the system during compilation.
 Dependencies may have different compile/configure approaches, so it may be tricky to integrate it to your build system.

6www.luxoft.com
Fetch dependencies sources during compilation
 You need internet to build our system
 Now you don’t have to apply security patches yourself.
 Servers are sometimes down.
 In 5/10/20 years appropriate sources may not be accessible via specified links.
 Compilation is still too long.
 You still need to find out how to install dependencies but not pollute the system with it.
 Build approach still may be different.
 If you use git for fetching sources, you should never use master branch - use specific tag instead.

7www.luxoft.com
Fetch dependencies binaries during compilation
 You need internet to build our system.
 Now you don’t have to apply security patches yourself.
 Servers are sometimes down.
 In 5/10/20 years appropriate sources may be not accessible by specified links.
 You still need to find out how to install dependencies but not pollute the system with it.

8www.luxoft.com
 Project is clear and contains only meaningful sources. That is nice.
 You require a developer to modify the system for application compilation.
 Dependencies on the system may have a different version.
 Dependencies on the system may be stored by unexpected paths: /opt, /home, etc.
 Dependencies may be patched or even “infected”. Do you really trust the user environment?
Use preinstalled compile time dependencies

9www.luxoft.com
 Project is clear and contains only meaningful sources. That is nice.
 Developer may build a container or fetch container binaries.
 Developer may recreate an environment on a local workstation and build as needed.
 Can be tricky to integrate with IDE.
 Build container can be extremely heavy, but I don’t feel like it’s an issue.
 Containers are not created for building in most cases: such usage is a bit of a hack.
Pack dependencies with container

10www.luxoft.com
Projects are so
different

11www.luxoft.com
 User desktop application
 Plugin/Shared library
 Web application
 Embedded application
 System service
 Kernel module
Project types

12www.luxoft.com
 Cross-compilation might be required
 Several cross-compilation targets might be required.
 Different compile options require different dependencies:
 Unit tests ON OFF
 Component tests ON OFF
 Some hardware/drivers usage ON/OFF
 Coverage, debug, linters, sanitizers, etc.
Compile options and targets

13www.luxoft.com
Canadian build

14www.luxoft.com
 Almost always cross-compilation is needed
 Output may be a firmware, not a binary.
 Yocto is widely used for such type of compilation.
 SDK layers should contain all required dependencies.
 You may need a team that takes care of SDK.
 Development environment may be delivered with docker or nix.
Embedded apps dependency management

15www.luxoft.com
 User should have an ability to compile it without major efforts.
 Build system should follow modern industry standards: cmake / make
 Users might want to use their own version of dependencies.
 Configure errors should be transparent.
Desktop/System apps dependency management

16www.luxoft.com
 You should provide Docker container with preinstalled environment for building applications.
 You should use modern industry standards: cmake / make
 You should use a modern cmake targets approach. It will be useful for embedding your app into another app.
 If user has already installed dependencies on the system with correct versions – use it.
 If dependencies are missed, use Fetch_content to download dependencies sources.
 Keep several backup URLs for dependencies fetching
 Keep forks of dependencies in case official repo is not available
 User should have an ability to redefine a search path for dependencies.
 Do not mix a dependency with application code. At least keep them in different folders or use submodules.
 Application cmakes.txt should not contain more than cmake find_package.
Mixed approach for most of cases of lib/system/desktop apps

17www.luxoft.com
Compile + runtime
dependencies
 Require preinstalled dependencies.
 Compile and deliver dependencies with the application.
 You may face DLL hell.
 You may deliver the application as flatpack/snap/brew/
 You may deliver the application via docker container.

18www.luxoft.com
 It is an industry standard
 So many ways to add projects:
 Submodule + add_subdirectory
 ExternalProject_Add
 find_package
 Use modern cmake. Follow https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1
 You can use FetchContent and ExternalProjectAdd, but only for small pet projects.
 Create .cmake file for each dependency and then include it.
 Try not to use custom variables - instead use standard CMAKE_PREFIX_PATH,CMAKE_INSTALL_PREFIX, etc …
 Leave the ability to use locally installed dependencies on the system.
Closer to code: cmake

19www.luxoft.com
 You are not using a dependency as a dependency – you are integrating it to your project. It may affect it with build flags, exported
variables, etc.
 Dependencies might have their own dependencies – it can lead to version mismatch
What’s wrong with add_subdirectory, FetchContent and ExternalProject add

20www.luxoft.com
 Problem that I can see there: Mixing dependency management and application compilation.
 Configure → Build → Compile→ Link
 Maybe something else before “Configure”?
Another level of abstraction can resolve any problem

21www.luxoft.com
Dependency management
is NOT a cmake
responsibility

22www.luxoft.com
So many ways to
solutions
 Conan
 Maven
 Meson
 apt/rpm/pacman/brew
 Nix
 Buckaroo
 Build2
 Docker
 Vcpkg
 Yocto
 CPM
 Venv
 NuGet

23www.luxoft.com
Conan
 Modern approach
 Runs before cmake
 Distributed (you can have our own bintray)
 Fetch dependencies binaries instead of sources
 Easily integrates with cmake in many different ways.
 Does not require major modifications of cmake. find_package is working.
 Sometimes some things are not working :-)
 Patching dependencies is possible but hard.
 Packages have various prebuild configurations
 Do not pollute the system
 Wonderful for desktop/library projects with popular dependencies like boost/opencv/poco/etc.

24www.luxoft.com
Nix package manager
 Not specific for C++ (contains enough software to make NixOS distro)
 The biggest package database
 Distributed, allows to contain own local caches
 Contains own functional language for package description
 Nix can even give you a compiler. nix-shell qtcreator gcc cmake boost and start development :-)
 Creating nixfile for the project allows to create a development environment that does not depend on the OS
(except Windows)
 Easily allows a full rebuild on local workstation
 nix-shell -p hello will open shell with hello program copied from cache
 nix-shell -p hello --option build-use-substitutes false will build hello program with dependencies locally

25www.luxoft.com
Nix package manager
 Not specific for C++ ( contains enough software to make NixOS distro)
 The biggest package database
 Distributed, allow to contain own local caches
 Contains own functional language for package description
 Nix can even give you a compiler. nix-shell qtcreator gcc cmake boost and start development :-)
 Creating nixfile for the project allows to create a development environment that doesn’t depend on the OS
(except Windows)
 Does not require integration with cmake. Emulates native package installation, but doesn’t pollute the system.
 Easily allows a full rebuild on local workstation
 nix-shell -p hello will open shell with hello program copied from cache
 nix-shell -p hello --option build-use-substitutes false will build hello program with dependencies locally

26www.luxoft.com
vcpkg
 Mostly same as previous ones
 Centralized
 Integrates to cmake via TOOL_CHAIN file
 Limited functionality (issue with building a shared lib)
 Maintained by Microsoft

27www.luxoft.com
vcpkg
 Mostly same as previous ones
 Centralized
 Integrates to cmake via TOOL_CHAIN file
 Limited functionality (issue with building a shared lib)
 Maintained by Microsoft

28www.luxoft.com
Build2
 Inspired by cargo from Rust
 Replaces cmake and make
 Mixes all abstraction levels (configure, build, deploy, testing, etc.), not unix way.
 Uses own Makefile like syntax for project description
 Modern and interesting view, maybe these guys have a clue.

29www.luxoft.com
Build2
 Inspired by cargo from Rust
 Replaces cmake and make
 Mixes all abstraction levels (configure, build, deploy, testing, etc.), not unix way.
 Uses own Makefile like syntax for project description
 Modern and interesting view, maybe these guys have a clue.

30www.luxoft.com
Final idea
 Use cmake, it is great.
 CMake should not do package management.
 Cmake should not depend on specific package management.
 You can have backup package management in cmake, but it is not
recommended.
 Docker is an easy way to establish build infrastructure, but it is not a
dependency manager, so it is not a production solution.
 There is a difference between internal and external dependencies.
 But even an internal dependency should be a separate project.

Aleksandr Kutsan "Managing Dependencies in C++"

More Related Content

What's hot (18)

Similar to Aleksandr Kutsan "Managing Dependencies in C++" (20)

More from LogeekNightUkraine (20)

Recently uploaded (20)

Aleksandr Kutsan "Managing Dependencies in C++"