Conan-izing an OpenGL project.

Now that I can build my app with Autotools, I want to make it work with conan. In my head, I have conan mapped to projects like cargo in rust and pip in Python. However, C++ has a far less homogenized toolchain, and I expect things are going to be more “how to make it work for you.” I started with Autotools to minimize that.

I did, however, install a few packages for development, and I am tempted to start by removing those packages and try to make conan do the work to fetch and install them.

 history | grep "apt install"
 2067  sudo apt install freeglut3-dev
 2095  sudo apt install  libboost-date-time-dev 
 2197  sudo apt install autoconf

So I removed those

sudo apt remove freeglut3-dev libboost-date-time-dev

Now, follow the same general pattern as the getting started guide:

conan search freeglut --remote=conancenter
Existing package recipes:

Because i am using python file instead of the file conanfile.txt, I have:

$ git diff
diff --git a/ b/
index a59fca3..b545ca0 100644
--- a/
+++ b/
@@ -40,3 +40,8 @@ class OrbitsConan(ConanFile):
     def package(self):
         autotools = Autotools(self)
+    def build_requirements(self):
+        self.tool_requires("boost/1.79.0")
+        self.test_requires("freeglut/3.2.1")

but when I try to install:

mkdir build
cd build
conan install ..

After much output, I get the error:

Installing (downloading, building) binaries...
ERROR: There are invalid packages (packages that cannot exist for this configuration):
freeglut/3.2.1: Invalid ID: freeglut does not support gcc >= 10 and clang >= 11

So…I guess we build that, too….nope. OK, going to punt on that for the moment, and see if I can get the rest to build, including boost. Comment out the freeglut line in and try again.

ERROR: Missing prebuilt package for 'boost/1.79.0'
Use 'conan search boost/1.79.0 --table=table.html -r=remote' and open the table.html file to see available packages
Or try to build locally from sources with '--build=boost'

OK, add in the –build boost flag as recommended. I am not certain that this is building the date library or not, and building all of boost might take a while….but no. Seems like it worked. Let’s try configure and build.

conan build .. 
/home/ayoung/devel/git/admiyo/orbits/./src/orbits.h:2:10: fatal error: boost/date_time/gregorian/gregorian.hpp: No such file or directory
    2 | #include "boost/date_time/gregorian/gregorian.hpp"

OK, let’s see if that is in the cached files from conan:

$ find  ~/.conan/ -name gregorian.hpp | grep date_time

So, yeah, it is there, but Autotools does not seem to be setting the include directory from the package. Looking back at the output from the previous command, I see that the g++ line only has these two -I flags.

-I. -I/home/ayoung/devel/git/admiyo/orbits/./src

I would expect that conan would implicitly add the includes directory from older packages to the build for a new package. However, that does not seem to be the case. I’ll look in to it. But for now, I can work around it by adding the directories myself. That is the power of using a full programming language like python as opposed to a Domain Specific Language. Here’s my build step:

    def build(self):
        env_build = AutoToolsBuildEnvironment(self)
        autotools = Autotools(self)
        for PATH in  env_build.include_paths:
            incdir = " -I%s"%PATH
            CXXFLAGS = CXXFLAGS + incdir
        os.environ["CXXFLAGS"] = CXXFLAGS

Note that I used the pdb mechanism pixelbeat wrote about way back. It let me inspect what was going on during the built process…huge time saver.

This might be why conan punts on the include path: I had to use environment variables to pass the additional values on down through Autotools to the Makefile. I don’t know cmake well enough to say whether it would have the same issue.

With this change added, the build completes to the point that I have a running orbit executable.

If this were part of a larger workflow, I would post this build to an internal conan repository server to be shared amongst the team. We’ll be doing that with the actual binaries used for production work.

Poking back at the FreeGLUT build, I see a couple things. First, if we look at the that was used to build it, we see that the check is right there in the code. We also see that it points to an old issue that was long ago fixed. Note that the link is not versioned, so if it gets changed, this article will not point to the error anymore.

I tried downloading that recipe and running it locally. It turns out that it depends on a slew of system packages (all of the X stuff required for OpenGL, etc). Which I installed. At that point, the build fails with:

CMake Error: The source directory “/home/ayoung/devel/conan/freeglut” does not appear to contain CMakeLists.txt.

And, while I could debug this, I decided that I am not going to pursue building against the package posted to central. For now, using system packages for the build seems to make more sense, especially for a dependency like FreeGLUT. If a larger ecosystem of native packages emerges, I might revisit this decision.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.