Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-66347

qt.conf - isn't solving a major problem for developers!

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Not Evaluated
    • Resolution: Duplicate
    • Affects Version/s: 5.10.0
    • Fix Version/s: None
    • Labels:
      None
    • Environment:
      MSVC 2017

      Windows 10

      Description

      Hi all,

      I went into a problem which is really really odd.

      What have I done so far?
      I built Qt on my machine under D:\Qt_src\5.10.0, shipped the build to another machine for development to C:\Qt\5.10.0 and include the path of the build into the Qt VS Tools under Qt Versions.

      What did I expected?
      I expected that Qt is that smart to find all its dependencies or a least a way to solve such a tiny problem. But I was wrong!

      Qt isn't able to detect the plugins and translation folders of the build. Furthermore I thought that the qt.conf from the 'bin' folder is used to solve the problem, but it's only used by the executables from that dir. (linguist, assistant, etc.)

      What have I done to solve the problem?
      There are several ways to solve this problem (like the docs mentioned), but none of the methods could be done by the build on its own.

      1. On the target machine setup a environment variable called QT_PLUGIN_PATH which leads to the ""missing"" folder.
        1. Disadvantage: You're no longer able to use other versions of the Qt builds as far as you don't change the variable everytime by switching between projects with different Qt Version.
      2. On the target machine add to each project the Qt version related qt.conf into the Resource file '/qt/etc/qt.conf'
        1. Disadvantage: I've an IDE which needs to solve such problems not me manually and forgetting a thousand time to put that file into each project.
        2. Disadvantage: At version switching or testing you need to remind yourself to change the qt.conf everytime.
      3. Put the qt.conf next to the compiled binary.
        1. (Disadvantage: Same as 2.)
      4. Set the QT_PLUGIN_PATH via qputenv at runtime before QApplication
        1. (Disadvantage: Same as 2.)
      5. QCoreApplication::setLibraryPaths
        1. (Disadvantage: Same as 2.)

      What needs to be done?
      To solve such a problem - why don't you use the qt.conf of the build dir for development? I mean it's nice to have such a method for built executables, but what about developers?

      If MSVC2017 is able to detect Qt5Widgetsd.dll from C:/Qt/5.10.0/bin, where the Qt VS Tools only knows about C:/Qt/5.10.0 why can't we use that path plus the Prefix of qt.conf itself to detect things like plugins for the IDE?

      QtDir ->  C:/Qt/5.10.0/
      BinDir -> bin/
      qt.conf -> Prefix=..
      Plugins -> plugins

      The solution would be:
      QtDir + BinDir + qt.conf:Prefix + QDir::separator() + Plugins
      "C:/Qt/5.10.0/" + "bin/" + ".." + "/" + "plugins"

       

      I couldn't think of any problem which would be created adding code for such a method.

      The qt.conf isn't capable of setting up another folder for 'bin' than 'bin' - so it's more or less a static folder which needs to be there.

      The main advantage would be a portable Qt build and less headache for developers.

      .. and at the end I'm asking myself: "What does Qt Creator make different than MSVC to detect the plugins folder or compile binaries with the right path to the folder?"

      Kind regards,
      Mike

        Attachments

          Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

            Activity

              People

              • Assignee:
                buddenha Oswald Buddenhagen
                Reporter:
                lachrymology Mike
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Gerrit Reviews

                  There are no open Gerrit changes