<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1" bgcolor="#FFFFFF">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">For what it's worth, what I've done here is to create binary packages of each third-party library for each supported platform (i.e. .deb packages for Ubuntu, .rpm packages for RHEL/CentOS,
Chocolatey packages for Windows). Except for cases where the system already provided sufficient versions of some of the libraries. At the bottom of the internal dependency chain is a base package which sets up the infrastructure (e.g. an /etc/profile.d file
to add a shell function to add entries to CMAKE_PREFIX_PATH, LD_LIBRARY_PATH, etc.) and at the top is a set of dependency metapackages, one for each product we have to build. And yes, the middle layer has a combination of large packages like Qt and Boost
with smaller packages like Expat and SQLite.<br>
<br>
Pluses:<br>
- Extremely convenient for an internal developer to just follow a few instructions to add our internal repository, then run "apt-get install anchorage-exata-deps".<br>
- Similarly convenient for customers developing custom code on top of our code if we provide an archive of the required packages, then they can point apt/yum/chocolatey to a file: URL.<br>
- It's not too difficult to support installing multiple parallel versions of the development environment for different versions of the product - just have each one install to a different location, and then the developer selects what to use by running the appropriate
shell function.<br>
- Greatly simplifies the CMake files for our code, since you just use the standard find_package() command (possibly requiring us to write a Find*.cmake module).<br>
- Flexibility of being able to easily experiment with a new or custom-compiled version of one of the dependencies.<br>
- If an internal developer happens to prefer working on a platform which we don't officially support (e.g. Debian testing or Mint), it's generally easy to git clone my packaging repositories and build packages for yourself.<br>
<br>
Minuses:<br>
- Duplicate packaging work for each different packaging tool when adding a new third-party library.<br>
- I haven't yet automated the process of building binary packages and uploading to our repository; so when updating any package to a new version (or adding a local patch) there's a lot of manual work to do. (dupload and reprepro help a bit for the Ubuntu builds,
and nuget has a built-in facility to upload to our server; but I haven't found anything similar for the RPM builds.)<br>
- When we do a release and then need to "fork" the repository to a new location, it requires a rebuild of all packages at least on Linux.<br>
<br>
Overall, most of the pluses apply to everybody, whereas the minuses are just a burden on me (or a future maintainer of the repository). So overall, it's been a big improvement over what we used to do, which was to try to maintain binary builds of the third-party
libraries in SVN.<br>
-- <br>
Daniel Schepler<br>
<span class="pl-s"></span>
<blockquote><span class="pl-s"></span></blockquote>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px"></div>
</div>
</body>
</html>