Bug#850243: forge: FTBFS on multiple architectures

[Ghislain Vaillant]

Now CC'd to the Debian CMake Team

On 05/01/17 12:26, Ghislain Vaillant wrote:
> CC'd  the Debian CMake Team, who might be able to help.
>
> On 05/01/17 10:48, Ghislain Vaillant wrote:
>> CC'd to the src:glm maintainer,
>>
>> On Thu, 05 Jan 2017 10:37:06 +0000 Ghislain Antony Vaillant
>> <ghisvail at gmail.com> wrote:
>>> Source: forge
>>> Version: 0.9.2-2
>>> Severity: serious
>>> Justification: fails to build from source (but built successfully in
>>> the past)
>>>
>>> Dear Maintainer,
>>>
>>> Since the latest update of the packaging, src:forge fails to build due
>>> to configuration error whilst looking for glm. Multiple architectures
>>> are affected, including major ones such as i386 or armhf / armel [1].
>>>
>>> [1] https://buildd.debian.org/status/logs.php?pkg=forge&ver=0.9.2-2
>>>
>>> Ghis
>>>
>>>
>>> -- System Information:
>>> Debian Release: stretch/sid
>>>   APT prefers testing
>>>   APT policy: (500, 'testing')
>>> Architecture: amd64 (x86_64)
>>>
>>> Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
>>> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
>>> Shell: /bin/sh linked to /bin/dash
>>> Init: systemd (via /run/systemd/system)
>>
>> Hi Guus, could you have a look at this please?
>>
>> It looks like it is due to a regression in glm introduced in 0.9.8.3
>> compared to 0.9.8.1. The CMake detection works correctly for amd64 but
>> not i386.
>>
>> The bug only shows up now because src:forge used to silently download a
>> copy of glm if a system version were not found. I have corrected this
>> behaviour and pushed a new version of the packaging, which now triggers
>> the CMake detection problem.
>>
>> Ghis
>
> Alright, this one is a bit tricky. Looking at the diff between 0.9.8.1
> and 0.9.8.3:
>
> ```
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index b7df09f..253eee5 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -164,7 +164,7 @@ set(GLM_INSTALL_CONFIGDIR
> "${CMAKE_INSTALL_LIBDIR}/cmake/glm")
>  install(DIRECTORY glm DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})
>
>  write_basic_package_version_file(
> -    "${CMAKE_CURRENT_BINARY_DIR}/glmVersion.cmake"
> +    "${CMAKE_CURRENT_BINARY_DIR}/glmConfigVersion.cmake"
>      VERSION ${GLM_VERSION}
>      COMPATIBILITY AnyNewerVersion
>  )
> @@ -188,7 +188,7 @@ configure_package_config_file(
>  install(
>      FILES
>
> "${CMAKE_CURRENT_BINARY_DIR}/${GLM_INSTALL_CONFIGDIR}/glmConfig.cmake"
> -        "${CMAKE_CURRENT_BINARY_DIR}/glmVersion.cmake"
> +        "${CMAKE_CURRENT_BINARY_DIR}/glmConfigVersion.cmake"
>      DESTINATION ${GLM_INSTALL_CONFIGDIR}
>  )
> ```
>
> It looks like the glm version lookup did not work before (because the
> version file was wrongly named) and has been fixed in the most recent
> release.
>
> Now if we inspect the content of glmConfigVersion.cmake, we find the
> following code, which I believe to be our culprit:
>
> ```
> # check that the installed version has the same 32/64bit-ness as the one
> which is currently searching:
> if(NOT CMAKE_SIZEOF_VOID_P STREQUAL "8")
>    math(EXPR installedBits "8 * 8")
>    set(PACKAGE_VERSION "${PACKAGE_VERSION} (${installedBits}bit)")
>    set(PACKAGE_VERSION_UNSUITABLE TRUE)
> endif()
> ```
>
> Hence the following outcome during the build in src:forge for any 32-bit
> architecture:
>
> ```
> CMake Error at src/backend/opengl/CMakeLists.txt:17 (FIND_PACKAGE):
>   Could not find a configuration file for package "glm" that is compatible
>   with requested version "".
>
>   The following configuration files were considered but not accepted:
>
>     /usr/lib/cmake/glm/glmConfig.cmake, version: 0.9.8 (64bit)
> ```
>
> So the question is how to instruct CMake to produce a ConfigVersion file
> without the above bit-ness check?
>
> Ghis