Bug#850243: forge: FTBFS on multiple architectures

[Ghislain Vaillant]

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