ECM Behaviour: Setting QT_PLUGIN_PATH on Windows
Hi all, We currently have a severe bug in ECM's AddTest macro due to it's behaviour around the setting of QT_PLUGIN_PATH. On Windows it would appear that the code in ECMAddTest mangles the environment variable, removing crucial paths that the CI system includes within this variable which are needed for applications and tests to function. As a consequence of this, several projects tests are broken, and some of these only fail by timeout. This has the effect of blocking Windows CI builders for several hours in some instances simply due to tests that are hanging and timing out as a result of being unable to load plugins. Can we please either short circuit this logic (and not try to set QT_PLUGIN_PATH on Windows) or figure out the correct logic to be used in this instance? My suspicion is that CMake treats ';' specially, which means that when the macro re-includes the existing content of the variable it gets mangled by CMake, resulting in the entire content of that variable being rendered unreadable. Alternatively, CMAKE_LIBRARY_OUTPUT_DIRECTORY could have a trailing backslash, which has certainly caused issues elsewhere. Thanks, Ben
Re: ECM Behaviour: Setting QT_PLUGIN_PATH on Windows
On Tue, Aug 28, 2018 at 10:35 PM Ben Cooksley wrote: > > Hi all, Hi all, > > We currently have a severe bug in ECM's AddTest macro due to it's > behaviour around the setting of QT_PLUGIN_PATH. On Windows it would > appear that the code in ECMAddTest mangles the environment variable, > removing crucial paths that the CI system includes within this > variable which are needed for applications and tests to function. > > As a consequence of this, several projects tests are broken, and some > of these only fail by timeout. This has the effect of blocking Windows > CI builders for several hours in some instances simply due to tests > that are hanging and timing out as a result of being unable to load > plugins. > > Can we please either short circuit this logic (and not try to set > QT_PLUGIN_PATH on Windows) or figure out the correct logic to be used > in this instance? > > My suspicion is that CMake treats ';' specially, which means that when > the macro re-includes the existing content of the variable it gets > mangled by CMake, resulting in the entire content of that variable > being rendered unreadable. > > Alternatively, CMAKE_LIBRARY_OUTPUT_DIRECTORY could have a trailing > backslash, which has certainly caused issues elsewhere. Based on the lack of response to this, along with my earlier mail to k-f-d 7 days ago it doesn't look like anyone's going to pick this up. As this issue is causing test breakages on the CI system including tying up valuable builder time for extraordinarily excessive amounts of time, i've taken a sledgehammer to the offending code in ECM. It should remain disabled until a proper solution can be found. > > Thanks, > Ben Regards, Ben
Re: ECM Behaviour: Setting QT_PLUGIN_PATH on Windows
On vendredi 31 août 2018 10:50:53 CEST Ben Cooksley wrote: > On Tue, Aug 28, 2018 at 10:35 PM Ben Cooksley wrote: > > Hi all, > > Hi all, > > > We currently have a severe bug in ECM's AddTest macro due to it's > > behaviour around the setting of QT_PLUGIN_PATH. On Windows it would > > appear that the code in ECMAddTest mangles the environment variable, > > removing crucial paths that the CI system includes within this > > variable which are needed for applications and tests to function. > > > > As a consequence of this, several projects tests are broken, and some > > of these only fail by timeout. This has the effect of blocking Windows > > CI builders for several hours in some instances simply due to tests > > that are hanging and timing out as a result of being unable to load > > plugins. > > > > Can we please either short circuit this logic (and not try to set > > QT_PLUGIN_PATH on Windows) or figure out the correct logic to be used > > in this instance? > > > > My suspicion is that CMake treats ';' specially, which means that when > > the macro re-includes the existing content of the variable it gets > > mangled by CMake, resulting in the entire content of that variable > > being rendered unreadable. > > > > Alternatively, CMAKE_LIBRARY_OUTPUT_DIRECTORY could have a trailing > > backslash, which has certainly caused issues elsewhere. > > Based on the lack of response to this, along with my earlier mail to > k-f-d 7 days ago it doesn't look like anyone's going to pick this up. > > As this issue is causing test breakages on the CI system including > tying up valuable builder time for extraordinarily excessive amounts > of time, i've taken a sledgehammer to the offending code in ECM. Is there any indication that this code was misbehaving on Unix as well? I'm surprised that you took out everything, not just the Windows case. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: ECM Behaviour: Setting QT_PLUGIN_PATH on Windows
On Sat, 8 Sep 2018, 20:12 David Faure, wrote: > On vendredi 31 août 2018 10:50:53 CEST Ben Cooksley wrote: > > On Tue, Aug 28, 2018 at 10:35 PM Ben Cooksley wrote: > > > Hi all, > > > > Hi all, > > > > > We currently have a severe bug in ECM's AddTest macro due to it's > > > behaviour around the setting of QT_PLUGIN_PATH. On Windows it would > > > appear that the code in ECMAddTest mangles the environment variable, > > > removing crucial paths that the CI system includes within this > > > variable which are needed for applications and tests to function. > > > > > > As a consequence of this, several projects tests are broken, and some > > > of these only fail by timeout. This has the effect of blocking Windows > > > CI builders for several hours in some instances simply due to tests > > > that are hanging and timing out as a result of being unable to load > > > plugins. > > > > > > Can we please either short circuit this logic (and not try to set > > > QT_PLUGIN_PATH on Windows) or figure out the correct logic to be used > > > in this instance? > > > > > > My suspicion is that CMake treats ';' specially, which means that when > > > the macro re-includes the existing content of the variable it gets > > > mangled by CMake, resulting in the entire content of that variable > > > being rendered unreadable. > > > > > > Alternatively, CMAKE_LIBRARY_OUTPUT_DIRECTORY could have a trailing > > > backslash, which has certainly caused issues elsewhere. > > > > Based on the lack of response to this, along with my earlier mail to > > k-f-d 7 days ago it doesn't look like anyone's going to pick this up. > > > > As this issue is causing test breakages on the CI system including > > tying up valuable builder time for extraordinarily excessive amounts > > of time, i've taken a sledgehammer to the offending code in ECM. > > Is there any indication that this code was misbehaving on Unix as well? > I'm surprised that you took out everything, not just the Windows case. > As far as I've seen it hasn't caused any issues on Unix so it should be fine to restore there. I disabled it for all as a precautionary measure as I wasn't sure if it was causing issues on Unix systems as well. Cheers, Ben > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 > > > >
