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

manual tests should be buildable standalone



    • Type: Bug
    • Status: Reported
    • Priority: P2: Important
    • Resolution: Unresolved
    • Affects Version/s: 6.2.0 Beta1
    • Fix Version/s: None
    • Component/s: Build System: CMake
    • Labels:


      On Teams it was suggested to use -DQT_BUILD_MANUAL_TESTS. That means building all Qt manual tests, which will increase build time. Besides, we have name conflicts: there is a manual test and an autotest both called qtabbar, more than one executable called "dialogs", the gifs manual test in controls2 was not buildable at all, etc. So it's currently not possible AFAICT.

      The other suggestion is to use qt-cmake-standalone-test, which seems ungainly.

      In Qt 5, it was convenient when somebody reports a bug that's hard to reproduce, to find a manual test that covers the functionality and ask them to build that and try it. It was as simple as going into the installed source directory, qmake and make. I don't know what I'd tell them now if that comes up. Apparently we even ship qt-cmake-standalone-test, but... why?!?

      The individual CMakeLists.txt do not have project(executable), nor minimum required version (two first things cmake complains about), but instead have internal magic like

      # special case begin
      if(NOT TARGET Qt::Svg OR NOT TARGET Qt::Quick OR NOT TARGET Qt::Qml)
      # special case end
      qt_internal_add_manual_test ...

      This isn't sustainable. We need a comprehensible build system. I'm not interested in cluttering my mind with cmake idiosyncracies that are not portable and obviously have their future in the trash bin anyway. Therefore for me, manual tests that I wrote myself are not accessible, because the .pro files are gone. There's not even a good reason for that, is there?

      If cmake can't be fixed, we should restore the .pro files. Probably we should anyway, for the sanity of the users. When I want to build one, I have to revert the patch that removed the .pro

      Maybe we should write complete standalone CMakeLists.txt for all these, but then I suppose that causes problems to automate the testing? But it's hard to believe nobody else has that problem, building multiple executables in subprojects. There must be a more standard solution.


          Issue Links

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



              qtbuildsystem Qt Build System Team
              srutledg Shawn Rutledge
              0 Vote for this issue
              3 Start watching this issue



                  Gerrit Reviews

                  There are no open Gerrit changes