Install broken if CMAKE_BUILD_TYPE not specified

[mwoehlke-kitware]

Related: flexible-collision-library/fcl#656

If the user does not specify CMAKE_BUILD_TYPE, the build root thinks the configuration is (empty string). However, due to include(CompilerSettings) in octomap/CMakeLists.txt, the actual library thinks it is Release. This results in the install step trying to install the configuration (empty string), but no corresponding exports exist, resulting in a broken installation.

This can be verified by the absense of octomap-targets-*.cmake files in an installation. For example:

FROM ubuntu:noble AS base

ENV DEBIAN_FRONTEND=noninteractive

RUN apt-get -qq update && \
    apt-get -qq --yes install \
        libeigen3-dev \
        libccd-dev \
        git \
        g++ \
        cmake \
        ninja-build

FROM base AS octomap

RUN git clone https://github.com/OctoMap/octomap /octomap

RUN mkdir /octomap/build && \
    cmake \
        -DCMAKE_POLICY_VERSION_MINIMUM=3.10 \
        -G Ninja \
        -S /octomap \
        -B /octomap/build

RUN cd /octomap/build && ninja install

Removing include(CompilerSettings) seems to fix the problem; as expected, a octomap-targets-noconfig.cmake gets generated and installed. Alternatively, moving include(CompilerSettings) to the root CMakeLists.txt likely solves the issue as long as octomap is built stand-alone. If the latter approach is preferred, consider guarding the inclusion with if(CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR) or something equivalent.

[ahornung]

@mwoehlke-kitware , thanks! Does this only affect the last releases (as the linked issues might hint) or also the current develop branch? There was a previous re-work of the CMake parts in #439 by @roehling that might have improved some things.

[mwoehlke-kitware]

It looks like it hasn't changed in devel. Check instances of include(CompilerSettings) and compare to suggestion(s) in the original description of this issue.

Also, feel free to pester me for more details if you aren't following anything.

[ahornung]

Also, feel free to pester me for more details if you aren't following anything.

Thanks, I might come back to that literally... but need to look into it deeper. What would be the preferred and most standard way to proceed, with the intention of defaulting to the Release build type if nothing is specified?

[mwoehlke-kitware]

Probably, add this to the root CMakeLists.txt:

if(CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
  include(CompilerSettings)
endif()

...and remove the other calls to include(CompilerSettings).

The if is to avoid still having the problem if someone is building OctoMap as a third-party library via add_subdirectory. While you won't get the 'default to RELEASE behavior' in that case, I don't think there's a safe way to get that with just include(CompilerSettings). The alternative is to ensure that CMAKE_BUILD_TYPE gets set in the cache if it's changed, but that isn't necessarily polite in the 'OctoMap being consumed via add_subdirectory' case.