cmake: internal architecture check breaks build

[ryandesign (Ryan Carsten Schmidt)]

Additional information: Cmake performs some internal architecture checks, based on the size of pointers to differentiate 32 and 64 bit binaries. This approach breaks builds on Macports when universal and non-universal ports are mixed. In particular, builds fail if trying to build a non-universal port on top of a universal one. The issue described below is a particular case, where kdepimlibs4 (non-universal) fails on top of akonadi+universal.

kdepimlibs4 fails to configure:

-- The following REQUIRED packages have not been found:

 * Akonadi (required version >= 1.10.1) , Akonadi server libraries , <http://pim.kde.org/akonadi>
   Access to PIM storage and services

CMake Error at /opt/local/share/cmake-2.8/Modules/FeatureSummary.cmake:430 (message):
  feature_summary() Error: REQUIRED package(s) are missing, aborting CMake
  run.
Call Stack (most recent call first):
  CMakeLists.txt:205 (feature_summary)

akonadi is installed:

$ port -v installed akonadi
The following ports are currently installed:
  akonadi @1.11.0_0+mariadb+universal-mysql5 (active) platform='darwin 13' archs='i386 x86_64'

[NicosPavlov]

I am afraid I am not able reproduce the issue, even when trying with mariadb and/or universal variants for akonadi. I looked in the configuration file of kdepimlibs4, and one thing which does not help is that the search for akonadi is set to QUIET, which reduces the amount of information leading to the issue. Perhaps removing it may provide more information about how the error occurs.

CMakeLists of Kdepimlibs4:

  #FindAkonadi.cmake is only there for compatibility reasons, but we don't want to use that.
  set(Akonadi_MIN_VERSION "1.10.1")
  find_package(Akonadi ${Akonadi_MIN_VERSION} QUIET NO_MODULE)
  set_package_properties(Akonadi PROPERTIES DESCRIPTION "Akonadi server libraries" URL "http://pim.kde.org/akonadi" TYPE REQUIRED PURPOSE "Access to PIM storage and services")

[ryandesign (Ryan Carsten Schmidt)]

Do I just remove the word QUIET from that find_package line? I did that, it still failed, and I don't know where to look for any additional information about why. There's no mention of akonadi in CMakeOutput.log or CMakeError.log.

[NicosPavlov]

In principle, removing the QUIET instruction should have provided more output in the main.log, to my understanding. As the find_package uses the NO_MODULE instruction, it means that it should be the file AkonadiConfig.cmake which sets the variables for the akonadi detection, and most of the checks in the file have an output. I do not see an obvious case in this file which could fail without providing an output.

[ryandesign (Ryan Carsten Schmidt)]

Replying to nicos@…:

In principle, removing the QUIET instruction should have provided more output in the main.log, to my understanding.

Ah yes, further back than I was looking:

CMake Warning at CMakeLists.txt:83 (find_package):
  Could not find a configuration file for package "Akonadi" that is
  compatible with requested version "1.10.1".

  The following configuration files were considered but not accepted:

    /opt/local/lib/cmake/Akonadi/AkonadiConfig.cmake, version: 1.11.0 (32bit)

Don't know where that "32bit" comes from; akonadi is installed universal for both i386 and x86_64.

[NicosPavlov]

Replying to ryandesign@…:

Don't know where that "32bit" comes from; akonadi is installed universal for both i386 and x86_64.

I agree this does not make sense, but it is probably the reason why it is not picked up during configuration. In this case, the issue seems more to be that akonadi should not indicate 32bit in the configuration file than kdepimlibs4 not picking it up. It seems that this is generated by a check in AkonadiConfigVersion.cmake:

# if the installed or the using project don't have CMAKE_SIZEOF_VOID_P set, ignore it:
if("${CMAKE_SIZEOF_VOID_P}"  STREQUAL ""  OR "4" STREQUAL "")
   return()
endif()

# 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 "4")
  math(EXPR installedBits "4 * 8")
  set(PACKAGE_VERSION "${PACKAGE_VERSION} (${installedBits}bit)")
  set(PACKAGE_VERSION_UNSUITABLE TRUE)
endif()

For reference, in my case (which builds fine), CMAKE_SIZEOF_VOID_P equals to 4, so that no (xxbit) is added to the version string.

[NicosPavlov]

I finally found how to reproduce the issue you reported. I had missed that you had tried to build kdepimlibs4 (not universal) on top of akonadi+universal. In this case, I get the same errors with the (32bit) inserted. It seems to go down to cmake, which does not consider universal bundles from apple. When building universal, it gives the one above (so only 32bit), while building only for x86_64 architecture provides:

"${CMAKE_SIZEOF_VOID_P}"  STREQUAL ""  OR "8" STREQUAL "")
[snip]
if(NOT "${CMAKE_SIZEOF_VOID_P}" STREQUAL "8")
  math(EXPR installedBits "8 * 8")
[snip]

(I dropped identical lines). The version check files are generated either by WriteBasicConfigVersionFile.cmake, or BasicConfigVersion-AnyNewerVersion.cmake.in.

I could probably patch akonadi to bypass the issue in case of universal build, but I suspect that this problem would propagate to other ports, so that it may be better to fix it directly in cmake.

[ryandesign (Ryan Carsten Schmidt)]

Huh, it does work when I build universal. Good catch.

Any configure script making decisions based on size of pointers is going to be broken with universal builds unless the muniversal portgroup is used. If all that's happening here is that one port's cmake script is checking that a dependency was installed with the right architectures, then I'd rip that out, since MacPorts already does that.

[NicosPavlov]

I think the attached patch suppresses the internal checks of cmake, but I am not really familiar with cmake internal code so that some input of the maintainer would be valuable. As the patched files are templates of cmake for other programs to build on, it means that the ports must be rebuilt for the change to kick in. I tested it with the case akonadi+universal and kdepimlibs4-universal, and it seems to work.

[NicosPavlov]

Maintainer timeout, committed in r115785.

[cooljeanius (Eric Gallager)]

Cc Me!