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
<ghisv...@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
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
