Wrong hard coded prefix path

[osechet]

When building Qt, the prefix path is hard coded. It leads to problems when the prefix given at the compilation time is not the same as the installation path. The prefix path is set during the make install step. As mentioned in conan-io/wishlist#2, it leads to problem to load plugins.

[osechet]

I think the make install step should be done by the package method() and the build() method should set the prefix to the final installation path. @memsharded Is there a way to know the package directory in the build() method (something similar to self.conanfile_directory)?

[jgsogo]

I've done a quick test in Windows7 (MSVC 14) and found the ¿same? issue:

This application failed to start because it could not find or load the Qt platform plugin "windows"
in "".

I solved it copying platforms/qwindows.dll from plugins dir to the directory where my executable is installed (see).

[osechet]

@jgsogo Have you tried to create a qt.conf file in the package directory? The file content should be something like:

[Paths]
Prefix = /path/to/the/package

I would like to reproduce the problem. If I create a simple GUI application, is it enough?

[jgsogo]

Windows 7

I tried to create the qt.conf file at several locations: package, working dir, exe dir,... but nothing worked. The application is so simple, you can check it out here

[jgsogo]

Ubuntu

I've tried what you told in https://github.com/conan-io/wishlist/issues/2 but it didn't work. Nevertheless I managed to run my app using the following qt.conf placed in the same directory as my executable (see).

[Paths]
Plugins = /home/javi/.conan/data/Qt/5.6.1-1/osechet/testing/package/41b4a670ac66e314bb644198013c12a53602fa3d/plugins

Now the application runs, but there is a problem with the fonts:

QFontDatabase: Cannot find font directory /home/javi/Programing/game-of-life/build/bin/lib/fonts - is Qt installed correctly?

---

I'm sorry to alternate between Win and Linux, I'll try to tag each message at the beginning, but I cannot access both computers at the same time, so Windows in the mornings and Ubuntu for the afternoons ^^

[memsharded]

Hi, @osechet sorry for the delay.

Yes, there is a package_folder that exists also in the build() step, you could use for that purpose. But if Qt hardcode this into the libraries, then there will be a problem anyway when reusing precompiled binaries (the path will be different for different users, computers, etc).

[jgsogo]

@memsharded, there is no problem in reusing precompiled binaries, from here (version 4.8):

The qt.conf file overrides the hard-coded paths that are compiled into the Qt library. These paths are accessible using the QLibraryInfo class. Without qt.conf, the functions in QLibraryInfo return these hard-coded paths; otherwise they return the paths as specified in qt.conf.

[osechet]

@jgsogo Yes, it works with qt.conf. However, it could be nice to be able to manage that file with conan. Almost everyone that will use the Qt package will run in the same issue as you if they don't manually create the qt.conf file. We have to find a way to avoid that.

[jgsogo]

I've haven't inspect conan workflow but I'm pretty sure that there is an event that does the "install" of Qt libraries to /.conan/data/..../package folder (inside the repo) and we would be able to override that to create our qt.conf file with the proper path for each user. Afterwards, we need something like:

def imports(self):
   self.copy("qt.conf", "", "bin")

Does it make sense?

[osechet]

The package creation and the package use are "disconnected". If the qt.conf file is created at the package creation, it will contains the path to the package on the creator's computer, e.g. /home/osechet/.conan/data/Qt/..... After it has been uploaded to the conan.io server, a conan user whose project depends on this package will download the qt.conf previously created. This file will be in his user's home directory, e.g. /home/jgsogo/.conan/data/Qt/... and the defined path will not match. I didn't see anything that call the package's conanfile during the download operation.

We need several things:

• First conan should run a kind of post-install step after it downloads a package. During this step, the Qt package could create a qt.conf file with the correct path.
• Then we need a way to copy the qt.conf file from the package directory to the user's application directory. The imports() method could be a solution but there is no way to ensure people will think about setting it.

[osechet]

After thinking a little bit more about the problem, I think the problem qith the qt.conf file is a build problem not a dependency problem. Even when you don't use Conan in a Qt project, you have to bundle a qt.conf file with your application. The problem cannot be solve with Conan. If you use CMake, it is easy to keep a qt.conf.in file with your source code and ask CMake to create the correct qt.conf file using variables.