FindBoost difference between Boost_INCLUDE_DIR and Boost_INCLUDE_DIRS

#1

Hi everyone,

Question is about the difference of using Boost_INCLUDE_DIR and Boost_INCLUDE_DIRS to indicate where boost header files are in the system.

As I understood so far from the documentation and from different posts on SO and other forums:

  • Boost_INCLUDE_DIR is cached after a first run of cmake in the project
  • Boost_INCLUDE_DIRS is set each time that cmake is run in the project

From the examples in the documentation, Boost_INCLUDE_DIRS is the variable used to indicate where boost header files are in the system.

But my question is, if we decided to use Boost_INCLUDE_DIR, should results be different that with Boost_INCLUDE_DIRS ?

Because in our library, we decided to go with Boost_INCLUDE_DIR, it worked so far. But one developer encountered an error because Boost_INCLUDE_DIR was empty (it was not Boost_INCLUDE_DIR-NOT_FOUND) and Boost_INCLUDE_DIRS was correctly set.

Our CMake scripts only does the following:

find_package(Boost 1.56 REQUIRED)
include_directories(${Boost_INCLUDE_DIR})

Thank you for any insights on the issue and have a nice day.

Julián

#2

Boost_INCLUDE_DIR is the directory Boost found for itself. This does not happen for BoostConfig.cmake based searches. Boost_INCLUDE_DIRS is the list of include directories needed to use Boost. This should include any directories to dependencies needed.

#3

Thank you for the answer !

I understand, but maybe the current naming or description of the variables is a bit confuse, what do you think ?

Because even in forums, the confusion happen, see:

  • this: tells users to go with Boost_INCLUDE_DIR
  • this: tells users to go with Boost_INCLUDE_DIRS

Both answer are accepted ones.

In my opinion the confusion comes from the variable name.

Anyway, we’ll change from Boost_INCLUDE_DIR to Boost_INCLUDE_DIRS in our library.

Julián

#4

It’s a typical pattern that things directly found are singular while aggregates which may include dependencies is plural. Since config.cmake files don’t need to actually search for anything, the singular variants tend to not exist and only the plural versions are “end results” of the find_package call. There are some older modules which have not migrated to this usage pattern however.