Re: [cmake-developers] Fwd: [CMake] cmake-gui on windows and qt5 dlls
On 08/14/2017 04:22 PM, Konstantin Podsvirov wrote: > 14.08.2017, 16:18, "Ben Boeckel" : >> On Mon, Aug 14, 2017 at 20:09:17 +1000, Craig Scott wrote: >>> moving cmake-gui and the Qt DLL's up to the top level? This may just be for >>> Windows, other platforms could stay as they are now. Would obviously have >>> to adjust not just the install location but also any internal code that >>> tries to work out where other files are located relative to the cmake-gui >>> executable. Things like the qt.conf file would also probably need some >>> adjustment. >> >> Git splits it between bin/ and cmd/ where cmd/ is meant to be in PATH. >> Then the structure doesn't need to change either. > > +1 Add script (.bat) to `cmd` subfolder to invoke tools from `bin` > on Windows (and add to PATH variable if needed). One could move `cmake-gui.exe` and `*.dll` files to some other out-of-the-way location and then have `bin/cmake-gui.exe` be a launcher that sets up the environment and runs the real `cmake-gui.exe`. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Fwd: [CMake] cmake-gui on windows and qt5 dlls
14.08.2017, 16:18, "Ben Boeckel" : > On Mon, Aug 14, 2017 at 20:09:17 +1000, Craig Scott wrote: >> It shouldn't be an issue having non-static Qt libs linked to cmake-gui, but >> as reported on the CMake users mailing list, it can be a problem when the >> directory cmake-gui is in is on the PATH. If CMake's bin directory appears >> on the PATH, the Qt DLL's bundled with it can take precedence over other >> applications' own Qt DLLs. The cmake and ccmake executables have a >> reasonable case for being on the PATH, but cmake-gui is typically going to >> be started via a desktop or menu icon and doesn't really need to be on the >> PATH. >> >> Rather than forcing static Qt libs to be used (I'm not aware of the reason >> for the change from static to dynamic Qt libs), we could instead move >> cmake-gui out of the bin directory so that it isn't in the same directory >> as the cmake and ccmake executables. This top level directory should never >> be added to the PATH, so it would resolve problems like the above. It is >> not unusual for the main executable to be in the top level directory of an >> installation rather than in a bin subdirectory. What do people think of >> moving cmake-gui and the Qt DLL's up to the top level? This may just be for >> Windows, other platforms could stay as they are now. Would obviously have >> to adjust not just the install location but also any internal code that >> tries to work out where other files are located relative to the cmake-gui >> executable. Things like the qt.conf file would also probably need some >> adjustment. >> >> Thoughts? > > Git splits it between bin/ and cmd/ where cmd/ is meant to be in PATH. > Then the structure doesn't need to change either. +1 Add script (.bat) to `cmd` subfolder to invoke tools from `bin` on Windows (and add to PATH variable if needed). > --Ben > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers Regards, Konstantin Podsvirov -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Fwd: [CMake] cmake-gui on windows and qt5 dlls
On Mon, Aug 14, 2017 at 20:09:17 +1000, Craig Scott wrote: > It shouldn't be an issue having non-static Qt libs linked to cmake-gui, but > as reported on the CMake users mailing list, it can be a problem when the > directory cmake-gui is in is on the PATH. If CMake's bin directory appears > on the PATH, the Qt DLL's bundled with it can take precedence over other > applications' own Qt DLLs. The cmake and ccmake executables have a > reasonable case for being on the PATH, but cmake-gui is typically going to > be started via a desktop or menu icon and doesn't really need to be on the > PATH. > > Rather than forcing static Qt libs to be used (I'm not aware of the reason > for the change from static to dynamic Qt libs), we could instead move > cmake-gui out of the bin directory so that it isn't in the same directory > as the cmake and ccmake executables. This top level directory should never > be added to the PATH, so it would resolve problems like the above. It is > not unusual for the main executable to be in the top level directory of an > installation rather than in a bin subdirectory. What do people think of > moving cmake-gui and the Qt DLL's up to the top level? This may just be for > Windows, other platforms could stay as they are now. Would obviously have > to adjust not just the install location but also any internal code that > tries to work out where other files are located relative to the cmake-gui > executable. Things like the qt.conf file would also probably need some > adjustment. > > Thoughts? Git splits it between bin/ and cmd/ where cmd/ is meant to be in PATH. Then the structure doesn't need to change either. --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Fwd: [CMake] cmake-gui on windows and qt5 dlls
Devs, It shouldn't be an issue having non-static Qt libs linked to cmake-gui, but as reported on the CMake users mailing list, it can be a problem when the directory cmake-gui is in is on the PATH. If CMake's bin directory appears on the PATH, the Qt DLL's bundled with it can take precedence over other applications' own Qt DLLs. The cmake and ccmake executables have a reasonable case for being on the PATH, but cmake-gui is typically going to be started via a desktop or menu icon and doesn't really need to be on the PATH. Rather than forcing static Qt libs to be used (I'm not aware of the reason for the change from static to dynamic Qt libs), we could instead move cmake-gui out of the bin directory so that it isn't in the same directory as the cmake and ccmake executables. This top level directory should never be added to the PATH, so it would resolve problems like the above. It is not unusual for the main executable to be in the top level directory of an installation rather than in a bin subdirectory. What do people think of moving cmake-gui and the Qt DLL's up to the top level? This may just be for Windows, other platforms could stay as they are now. Would obviously have to adjust not just the install location but also any internal code that tries to work out where other files are located relative to the cmake-gui executable. Things like the qt.conf file would also probably need some adjustment. Thoughts? -- Forwarded message -- From: Craig Scott Date: Mon, Aug 14, 2017 at 7:47 PM Subject: Re: [CMake] cmake-gui on windows and qt5 dlls To: Christian Ehrlicher Cc: CMake This is a common problem, not just with CMake. I'm wondering if there's any real need for cmake-gui to be on the PATH at all, since it will usually be invoked by a desktop or menu icon. At the moment though, it is in the same directory as the cmake and ccmake executables which have a much stronger case for being on the PATH. There's a reasonable argument that cmake-gui should be in a different directory, then it wouldn't be an issue if shared Qt libs were used rather than static. I'll bring this up on the developer mailing list and see what discussions yield. On Mon, Aug 14, 2017 at 6:22 PM, Christian Ehrlicher wrote: > Hi, > > I recently upgraded from cmake 3.3 to 3.9 on windows and got some problems > during my build because it looks like the pre-compile binaries for windows > are now shipping Qt5 - dlls instead static compile libs (since 3.5 afaics). > The problem is, that I had the path to cmake *before* the path to my own > Qt5 libaries. So during the build / run of my application, the wrong > libraries were loaded and I got a symbol lookup error. > Would it be possible to use the static Qt5 libs instead or maybe prefix > the Qt5 libs shipped with cmake-gui somehow? > > Thx, > Christian > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Craig Scott Melbourne, Australia https://crascit.com -- Craig Scott Melbourne, Australia https://crascit.com -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
