[Development] Setting CMAKE_PREFIX_PATH to Qt prefix breaks use of system ICU via CMake

Thiago Macieira thiago.macieira at intel.com
Sat Apr 29 22:06:29 CEST 2017


On Saturday, 29 April 2017 06:22:20 -03 Konstantin Tokarev wrote:
> > Out of scope and you should be using qmake.
> 
> I understand your point, but it seems impractical to provide wrapper qmake
> project as an interface for packagers. They know know how to deal with
> qmake or cmake packages, but dealing with cmake wrapped with qmake is a
> totally different business, and can easily double amount of issues to
> solve, especially when cross-compiling. That said, it works fine in Coin.

My point is that there should be no cmake involved at all. The qtwebkit build 
has worked with qmake for 10 years, why should it stop now?

> Maintaining old qmake-based build was not considered because I don't have
> resources to maintain a build system that duplicate's one maintained by
> upstream. If there are volunteers to do that I can reconsider, but note
> that you will have to deal with lots of custom code generators, that are
> changed over time, and it would be much harder to backport upsream patches
> (that already include necessary cmake changes)

Was the one that used to exist removed?

> As a side effect, having cmake build that is usable as a public build
> interface helps with IDE integration, e.g. I'm using existing cmake support
> in Qt Creator for development.

And the existing qmake support in Qt Creator did not work?

> >>  * Remove unversioned symlinks like libicuuc.so from SDK, so that they
> >>  are not found by FindICU.cmake, and also by linker if it's given -licuuc
> > 
> > That seems like the right solution for me. If we're not supplying the
> > headers (and it's not our business to), then we shouldn't supply the *.so
> > symlinks either.
> 
> Fine with me. Looks like the problem is that archive [1] contains only
> necessary files, but [2] contains all ICU libraries + unversioned links.
> Archive [2] is unpacked into SDK image since 5.8.0.

Then let's do it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Development mailing list