We were thinking about switching to prebuilt binaries
but we still would like to leave a possibility to return back to source code
so first of all you'll need a build system, which I recommend you to use cmake to handle your source code and its dependencies.
Lets get a testing setup here, and let assume your working directory looks like this:
project_folder
|-- lib
| |-- LibA.cpp
| |-- LibA.hpp
|-- tools
| |-- conanfile.py
| |-- conanfile.txt
|-- CMakeLists.txt
|-- main.cpp
what are they suppose to be: CMakeLists.txt
is your cmake
configuration file, to handle
Is it possible to identify Api/abi breaks ?
and conanfile.py
is your recipe, means what you need to package and create your pre-built libraries and conanfile.txt
is your require file for consuming your pre-built libraries.
so apparently, I also suggest to use conan to handle your pre-built libraries, or also called as packages.
Now lets get through my example and how to use it:
CMakeLists.txt:
cmake_minimum_required(VERSION 3.15)
project(my_project LANGUAGES CXX)
add_library(LibA lib/LibA.cpp)
add_executable(ExecutableA main.cpp)
target_link_libraries(ExecutableA LibA)
target_include_directories(LibA PUBLIC ${CMAKE_CURRENT_LIST_DIR}/lib)
I'll stick on cpp
in my example, but for your .net
framework, you could check this or this
So I just define my targets
in that files, and declare its dependencies with each others, with following contents:
main.cpp:
#include <iostream>
#include "LibA.hpp"
int main()
{
printTesting();
std::cout << "Hello World! again" << std::endl;
return 0;
}
LibA.cpp:
#include <iostream>
#include "LibA.hpp"
void printTesting(void)
{
std::cout << "Testing Something" << std::endl;
}
LibA.hpp:
#include <iostream>
void printTesting(void);
I just assume, you are not familiar with cmake: we'll let cmake generate the Makefile
for us, or for you evtl. the .vcxproj
if you use .net
generator, but I want to keep it simple here, so we'll configure the project and build the binaries.
mkdir ../build && cd ../build
cmake ../project_folder && make
you'll get your LibA
and ExecutableA
, so nothing special here yet, just that cmake
now take care of your dependencies, and evtl. rebuild them if something has changed (e.g. new commits in your projects).
with conanfile.py like this:
from conans import ConanFile, tools
class LibAConan(ConanFile):
name = "libA"
version = "0.1"
settings = "os", "compiler", "build_type", "arch"
description = "<Description of LibA here>"
url = "None"
license = "None"
author = "None"
topics = None
def package(self):
self.copy("*.a")
def package_info(self):
self.cpp_info.libs = tools.collect_libs(self)
you want to:
cp ../project_folder/tools/conanfile.py && conan export-pkg . libA/0.1@myuser/testing
with our package name is: libA
in 0.1
version. myuser/testing
is the channel, which is interesting incase your doing cross-compilation for several target plattforms.
We created the reusable package by calling conan export-pkg
, and this is cached in
$HOME_DIR/.conan/data/libA/0.1/myuser/testing
(or check it in you environment: conan config home
)
Evtl. you want to install conan first, so check this installation guideline or this downloads and for your special setup: conan with azure devops
So those created packages could also be uploaded to any remote_server:
$ conan upload libA/0.1@myuser/testing --all -r=my_remote_server
(as analogy: like git push
after commiting in git).
So we have configured
, built
with cmake and created
and uploaded
packages using conan, your colleagues could reused the prebuilt packages/binaries by define their requirement in pythonfile.txt:
[requires]
libA/0.1@myuser/testing
[generators]
cmake
and they could do:
mkdir ../build_using_prebuild && cd ../build_using_prebuild && cp ../project_folder/tools/conanfile.txt . && conan install -g deploy . -r my_remote_server
conan will search for that required package and evlt. download it from my_remote_server
If they now run cmake ../project_folder && make
, those prebuilt packages will be used, instead of compiling the src from scratch.
Of course I recommend you to automatise those steps in azure, but I guess you got the points how the build system and package manager could be used to orchestrate your build.