![]() I have chosen boost to show an example of using docker with a “heavy” third party.Ĭmake_minimum_required (VERSION 3.10.2 ) project (a.out ) set (CMAKE_CXX_STANDARD 17 ) set (CMAKE_CXX_STANDARD_REQUIRED ON ) # Remove for compiler-specific features set (CMAKE_CXX_EXTENSIONS OFF ) string (APPEND CMAKE_CXX_FLAGS " -Wall" ) string (APPEND CMAKE_CXX_FLAGS " -Wbuiltin-macro-redefined" ) string (APPEND CMAKE_CXX_FLAGS " -pedantic" ) string (APPEND CMAKE_CXX_FLAGS " -Werror" ) # clangd completion set (CMAKE_EXPORT_COMPILE_COMMANDS ON ) include_directories ( $,target=/src it instructs docker to mount the current directory (where the source code is located) to the directory src. The application will print its size with boost::filesystem. Let us create a simple application and build it in a container. All this makes the dockerized build environment reproducible. Thus, it is always possible to rebuild the image from an old Dockerfile. Even if the image has been removed from the registry, docker images, as well known, are built from Dockerfiles which in their turn are part of git repositories. Ideally, docker images are properly tagged with some meaningful version names it allows users to jump between environments by pulling the right image from the registry. Since the build runs inside of a container, it is not affected by any environment variables, tools, or settings specific to a developer’s local environment, which means that the environment becomes isolated. no more “it works on my machine but fails at CI!”. This image will be the base of a single build environment used by developers on their workstations and CI/CD servers, i.e. ![]() The preferred solution to the problems mentioned above is to create a docker image with preinstalled dependencies and tools such as compilers, debugger, etc, and build the project inside a container based on this image. Solutions like Conan often lack the right version of a certain dependency and adding it requires writing code in Python, which from my point of view is a bit too much.Ī single, isolated, and reproducible build environment.In cases when a 3rd party is heavy (boost, Protobuf, Thrift, etc), this approach may slow down the build so significantly that developers become reluctant to clean a build directory or switch between branches. Adding 3rd parties as git submodules requires building them within the project’s source tree.Installing dependencies on a dev machine makes the environment dirty and rarely the same as CI/CD or production, especially after updating the 3rd parties.Unfortunately, all of them have certain disadvantages: apt-get) or via “make install”, adding 3rd parties as git submodules and building them within the source tree, or using a half-baked solution like Conan. C++ does not provide a built-in dependency management mechanism and as a result, third parties are added using a mix of techniques: installing from Linux distro’s repositories (e.g. Common problems of building projects “natively” on a workstationįirst of all, let us discuss why building C/C++ projects directly on a workstation may become a problem. In this post, I will share how to create a docker-based build environment for C and C++ projects targeted for Linux.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |