Bug 386756 - ECM doesn't allow newer KF5 64bit packages
Summary: ECM doesn't allow newer KF5 64bit packages
Status: RESOLVED WORKSFORME
Alias: None
Product: extra-cmake-modules
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.39.0
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: ecm-bugs-null@kde.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-11 18:30 UTC by Uwe Stöhr
Modified: 2017-11-12 23:06 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Uwe Stöhr 2017-11-11 18:30:03 UTC
I want to build the KDE program LabPlot on Windows. Therefore I use the latest craft, CMake 3.9.5, Python 3.6.3, Qt 5.9.2 and ECM 5.39.0

But whenever I run CMake, I get this error:

CMake Warning at C:/CraftRoot/share/ECM/find-modules/FindKF5.cmake:74 (find_package):
  Could not find a configuration file for package "KF5Archive" that is
  compatible with requested version "5.16.0".

  The following configuration files were considered but not accepted:
    C:/CraftRoot/lib/cmake/KF5Archive/KF5ArchiveConfig.cmake, version: 5.39.0 (64bit)

Call Stack (most recent call first):
  CMakeLists.txt:21 (find_package)
Could NOT find KF5Archive , checked the following files:
    C:/CraftRoot/lib/cmake/KF5Archive/KF5ArchiveConfig.cmake (version 5.39.0 (64bit))

I asked thre developer of LabPlot and they hae also no explanation than there is a bug in ECM. Therefore I report this here.

To me it seems as if the "(64bit)" in the package name causes the bug but I am not sure.
Comment 1 Christophe Marin 2017-11-11 18:54:30 UTC
It only complains about karchive ? Did you try rebuilding this module ?
Comment 2 Uwe Stöhr 2017-11-12 01:46:41 UTC
rebuilding karchive doesn't help

It does not only complain with karchive but with all other KF5 packages used by labplot: KF5Archive, KF5Completion, KF5Config ...

I thought it might be a problem with Qt and therefore tried to use the prebuilt librarion directly from the Qt installer. In my craftsettings.ini and have now this:

[QtSDK]
## For advanced users only
## Whether to use prebuild Qt binaries.
Enabled = True
## The path to the Qt sdk.
Path = C:\Qt\Qt5.9.2\5.9.2\msvc2015_64\bin
## The version of Qt.
Version = 5.9.2
## The compiler version, if you are not sure what to use, have a look into the derectory set in QtSDK/Path.
## The compiler must be of the same type as General/KDECOMPILER.
## If you are using mingw please make sure you have installed the mingw using the Qt installer.
Compiler = msvc2015_64

But then I get this error when recompiling karchive:
  Could not find a package configuration file provided by "Qt5" (requested
  version 5.7.0) with any of the following names:

    Qt5Config.cmake
    qt5-config.cmake

  Add the installation prefix of "Qt5" to CMAKE_PREFIX_PATH or set "Qt5_DIR"
  to a directory containing one of the above files.  If "Qt5" provides a
  separate development package or SDK, be sure it has been installed.

But in the path I specified:
C:\Qt\Qt5.9.2\5.9.2\msvc2015_64\bin
there is the Qt5Config.cmake

I don't know how to proceed.
Comment 3 Christophe Marin 2017-11-12 08:19:28 UTC
Which CMake version do you use ?
Comment 4 Christophe Marin 2017-11-12 08:20:04 UTC
(In reply to Christophe Giboudeaux from comment #3)
> Which CMake version do you use ?

never mind, it's in the first post, sorry
Comment 5 Hannah von Reth 2017-11-12 11:50:47 UTC
This is not a cmake bug but it looks like you mixed binaries and your configuration.

Can you please paste your ABI setting? Did you change it after you build some libraries? 
Can you paste the output of "where.exe cl" when called in your craft env?
Comment 6 Uwe Stöhr 2017-11-12 15:03:10 UTC
> Can you please paste your ABI setting?

Craft Root          : C:\CraftRoot
Craft               : R:\
Version             : master
ABI                 : windows-msvc2015_64-cl
Svn directory       : C:\CraftRoot\download\svn
Git directory       : Q:\
Download directory  : C:\CraftRoot\download

> Did you change it after you build some libraries? 

No, I only have MSVC 2015 and it has always been the 64bit version.

> Can you paste the output of "where.exe cl" when called in your craft env?

C:\Programme (x86)\MSVC2015\VC\bin\amd64\cl.exe
Comment 7 Hannah von Reth 2017-11-12 15:15:20 UTC
Ah now I saw the problem.
It cant find Qt because 
## The path to the Qt sdk.
Path = C:\Qt\Qt5.9.2\5.9.2\msvc2015_64\bin 
is wrong

It usually should be something like
Path=C:\Qt
Its meant to be the path where Qt is installed to, not the single version but the whole installation.
Comment 8 Uwe Stöhr 2017-11-12 15:42:12 UTC
> It usually should be something like
> Path=C:\Qt

Ah, I found now the correct path, see
https://bugs.kde.org/show_bug.cgi?id=386776

So my status is now the following:
1. at first I removed Craft completely
2. restarted Windows to start with a clean system
3. installed Craft following
https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/Windows
4. in the craftsettings.ini I chose to get Release builds, not RelwithDebugInfo
5. installed ECM and karchive via craft

Now ECM find karchive. I am pretty sure I haven't dome anything else than
- using release builds
- using the prebuilt Qt 5.9.2 libraries

So for now it seems to work, except that I still cannot compile labplot because some framework packages fail, see
https://bugs.kde.org/show_bug.cgi?id=386776
Comment 9 Uwe Stöhr 2017-11-12 15:53:31 UTC
> Now ECM find karchive. I am pretty sure I haven't dome anything else than
> - using release builds
> - using the prebuilt Qt 5.9.2 libraries

I also tried it out with 
RelWithDebInfo
instead of
Release
in craftsettings.ini. I recompiled karchive using
craft -i karchive
the I deleted all CMake staff for labplot, and set up a new CMake project.
This works too.

So the only explanation for the bug I encountered is that I used the Qt libraries from craft and not the prebuilt ones from the official Qt for Windows installer for MSVC 2015.

I read that KDE is patching Qt for their needs and maybe a mistake slipped in? From other projects they recommend to use only the official Qt installer for Windows. So maybe one should advise in
https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/Windows
that one should use an installed Qt.
Comment 10 Hannah von Reth 2017-11-12 17:22:24 UTC
I'm not sure what your current problem is?
Comment 11 Uwe Stöhr 2017-11-12 18:52:09 UTC
> I'm not sure what your current problem is?

When I compile karchive using the default settings in QtSDK (Qt libraries via craft9 then I get the bug in my initial comment of this bug report.

When I compile using the installed Qt from qt.io (setting a QtSDK) it works. So there must be a bug either in EC or in the Qt libraries that come from craft.
Comment 12 Hannah von Reth 2017-11-12 19:18:16 UTC
Your initial problem was probably caused by a wrong setup, an x86 compiler in path when you where building for x64 or something like that.
Comment 13 Uwe Stöhr 2017-11-12 19:50:02 UTC
> Your initial problem was probably caused by a wrong setup, an x86 compiler in path when you where building for x64 or something like that.

OK, let's close it for now.