Re: [CMake] cmake-gui on windows and qt5 dlls

[Craig Scott]

On Fri, Aug 18, 2017 at 6:23 AM, Craig Scott 
wrote:

>
>
> On Fri, Aug 18, 2017 at 5:05 AM, Konstantin Podsvirov <
> konstan...@podsvirov.pro> wrote:
>
>> Hello Clément Gregoire!
>>
>> 17.08.2017, 21:55, "Clément Gregoire" :
>> > So the following worked for me:
>> >
>> > move cmake-gui.exe, all dlls and qt.conf to a "cmkae/bin/gui" subfolder
>> >
>> > create a batch file named
>> >
>> > cmake-gui.bat
>> >
>> > with the following content
>> >
>> > @echo off
>> > start "" /B "%~dp0\gui\cmake-gui.exe" %*
>> >
>> > And modify qt.conf so that the plugin directory is correct :
>> >
>> > from  Plugins = ../plugins toPlugins = ../../plugins
>> >
>> > I'm not (yet) on the dev mailing list, so feel free to transfer the
>> solution there.
>>
>> Please review dev mailing list archive too:
>> http://public.kitware.com/pipermail/cmake-developers/2017-Au
>> gust/030228.html
>> (may be I forgot /B option)
>>
>
> Side note: really weird, but that email you've linked to never made it to
> my inbox (can't explain it, checked my trash and spam folders too), so I
> never saw your request to ask to test!
>
> In the past, one problem I've run into with using simple batch files as
> launcher scripts is that they can flash up a console window briefly before
> starting the real app. This can look suspicious and distracting to the
> user, so it is something to avoid. I think at one past employer we ended up
> using something like wscript instead, which allowed us to avoid that
> problem and it worked on all Windows versions without any extra software
> dependencies. Maybe we just didn't have good enough batch-file-fu, maybe
> things work differently now, I don't know. Been a number of years since
> I've looked at that specific problem. Some context, but only basic extra
> info:
>
> https://stackoverflow.com/a/9062764/1938798
>

Let me clarify the above (sorry, recalling more of the original problem we
had years back). The flashing up of a console window would occur if you ran
the launcher from somewhere other than an existing console window. For
example, if you double-clicked the launcher in Windows Explorer or via a
menu shortcut. In our case, we were using the script to set some
environment variables before launching the real app, so you always wanted
to use the launcher. In the discussion here about cmake-gui, you don't
really need that, you just want a way to forward the call to start the app
so you can avoid putting the real app and its DLLs on the PATH. So I guess
a batch file would be okay in this instance, since we would only be
expecting people to use it from a console window anyway (menu shortcuts,
etc. could still invoke the real cmake-gui app directly).


-- 
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

Re: [CMake] cmake-gui on windows and qt5 dlls

[Craig Scott]

On Fri, Aug 18, 2017 at 5:05 AM, Konstantin Podsvirov <
konstan...@podsvirov.pro> wrote:

> Hello Clément Gregoire!
>
> 17.08.2017, 21:55, "Clément Gregoire" :
> > So the following worked for me:
> >
> > move cmake-gui.exe, all dlls and qt.conf to a "cmkae/bin/gui" subfolder
> >
> > create a batch file named
> >
> > cmake-gui.bat
> >
> > with the following content
> >
> > @echo off
> > start "" /B "%~dp0\gui\cmake-gui.exe" %*
> >
> > And modify qt.conf so that the plugin directory is correct :
> >
> > from  Plugins = ../plugins toPlugins = ../../plugins
> >
> > I'm not (yet) on the dev mailing list, so feel free to transfer the
> solution there.
>
> Please review dev mailing list archive too:
> http://public.kitware.com/pipermail/cmake-developers/2017-
> August/030228.html
> (may be I forgot /B option)
>

Side note: really weird, but that email you've linked to never made it to
my inbox (can't explain it, checked my trash and spam folders too), so I
never saw your request to ask to test!

In the past, one problem I've run into with using simple batch files as
launcher scripts is that they can flash up a console window briefly before
starting the real app. This can look suspicious and distracting to the
user, so it is something to avoid. I think at one past employer we ended up
using something like wscript instead, which allowed us to avoid that
problem and it worked on all Windows versions without any extra software
dependencies. Maybe we just didn't have good enough batch-file-fu, maybe
things work differently now, I don't know. Been a number of years since
I've looked at that specific problem. Some context, but only basic extra
info:

https://stackoverflow.com/a/9062764/1938798

-- 
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

Re: [CMake] cmake-gui on windows and qt5 dlls

[Konstantin Podsvirov]

Hello Clément Gregoire!

17.08.2017, 21:55, "Clément Gregoire" <lec...@gmail.com>:
> So the following worked for me:
>
> move cmake-gui.exe, all dlls and qt.conf to a "cmkae/bin/gui" subfolder
>
> create a batch file named
>
> cmake-gui.bat
>
> with the following content
>
> @echo off
> start "" /B "%~dp0\gui\cmake-gui.exe" %*
>
> And modify qt.conf so that the plugin directory is correct :
>
> from  Plugins = ../plugins to    Plugins = ../../plugins
>
> I'm not (yet) on the dev mailing list, so feel free to transfer the solution 
> there.

Please review dev mailing list archive too:
http://public.kitware.com/pipermail/cmake-developers/2017-August/030228.html
(may be I forgot /B option)

> 2017-08-14 15:33 GMT+02:00 Lectem <lec...@gmail.com>:
>> Right, as mentionned by Craig Scott, a script might do the trick ? Just a 
>> cmake-gui.bat that calls cmake-gui.exe should work.
>>
>> De : Robert Maynard
>> Envoyé le :lundi 14 août 2017 15:24
>> À : Craig Scott
>> Cc : Clément Gregoire; CMake
>> Objet :Re: [CMake] cmake-gui on windows and qt5 dlls
>>
>> More importantly symlinks are restricted to administrator accounts
>>
>> only in Windows Vista/7/8. Windows 10 with Developer Mode activated
>>
>> allows none-elevated accounts to create symlinks.
>>
>> This is important as CMake does ship non-installer windows binaries.
>>
>> On Mon, Aug 14, 2017 at 9:00 AM, Craig Scott <craig.sc...@crascit.com> wrote:
>>
>>>
>>
>>>
>>
>>> On Mon, Aug 14, 2017 at 9:05 PM, Clément Gregoire <lec...@gmail.com> wrote:
>>
>>>>
>>
>>>> Wouldn't it be possible to move it to a subfolder with the DLLs and put a
>>
>>>> link next to cmake and ccmake? Executables look for DLLs in their directory
>>
>>>> and it wouldn't pollute the PATH
>>
>>>
>>
>>>
>>
>>> Symlinks are available on NTFS filesystems from Vista onwards. If the user
>>
>>> installed CMake on, say, a FAT filesystem instead or on an old XP box (CMake
>>
>>> appears to still try to support that), then symlinks wouldn't be available
>>
>>> from what I can make out. One could potentially use a forwarding script of
>>
>>> some kind though to achieve essentially the same thing.
>>
>>>
>>
>>>
>>
>>>> I personally like to be able to launch it through the command line, it is
>>
>>>> faster than looking for it and then browse for the folder.
>>
>>>>
>>
>>>>
>>
>>>> Le lun. 14 août 2017 à 11:48, Craig Scott <craig.sc...@crascit.com> a
>>
>>>> écrit :
>>
>>>>>
>>
>>>>> 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
>>
>>>>> <ch.ehrlic...@gmx.de> 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

Re: [CMake] cmake-gui on windows and qt5 dlls

[Clément Gregoire]

So the following worked for me:


move cmake-gui.exe, all dlls and qt.conf to a "cmkae/bin/gui" subfolder

create a batch file named

cmake-gui.bat

with the following content

@echo off
start "" /B "%~dp0\gui\cmake-gui.exe" %*

And modify qt.conf so that the plugin directory is correct :

from  Plugins = ../plugins toPlugins = ../../plugins


I'm not (yet) on the dev mailing list, so feel free to transfer the
solution there.


2017-08-14 15:33 GMT+02:00 Lectem <lec...@gmail.com>:

> Right, as mentionned by Craig Scott, a script might do the trick ? Just a
> cmake-gui.bat that calls cmake-gui.exe should work.
>
>
>
> *De : *Robert Maynard <robert.mayn...@kitware.com>
> *Envoyé le :*lundi 14 août 2017 15:24
> *À : *Craig Scott <craig.sc...@crascit.com>
> *Cc : *Clément Gregoire <lec...@gmail.com>; CMake <cmake@cmake.org>
> *Objet :*Re: [CMake] cmake-gui on windows and qt5 dlls
>
>
>
> More importantly symlinks are restricted to administrator accounts
>
> only in Windows Vista/7/8. Windows 10 with Developer Mode activated
>
> allows none-elevated accounts to create symlinks.
>
>
>
> This is important as CMake does ship non-installer windows binaries.
>
>
>
> On Mon, Aug 14, 2017 at 9:00 AM, Craig Scott <craig.sc...@crascit.com>
> wrote:
>
> >
>
> >
>
> > On Mon, Aug 14, 2017 at 9:05 PM, Clément Gregoire <lec...@gmail.com>
> wrote:
>
> >>
>
> >> Wouldn't it be possible to move it to a subfolder with the DLLs and put
> a
>
> >> link next to cmake and ccmake? Executables look for DLLs in their
> directory
>
> >> and it wouldn't pollute the PATH
>
> >
>
> >
>
> > Symlinks are available on NTFS filesystems from Vista onwards. If the
> user
>
> > installed CMake on, say, a FAT filesystem instead or on an old XP box
> (CMake
>
> > appears to still try to support that), then symlinks wouldn't be
> available
>
> > from what I can make out. One could potentially use a forwarding script
> of
>
> > some kind though to achieve essentially the same thing.
>
> >
>
> >
>
> >> I personally like to be able to launch it through the command line, it
> is
>
> >> faster than looking for it and then browse for the folder.
>
> >>
>
> >>
>
> >> Le lun. 14 août 2017 à 11:48, Craig Scott <craig.sc...@crascit.com> a
>
> >> écrit :
>
> >>>
>
> >>> 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
>
> >>> <ch.ehrlic...@gmx.de> 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 

Re: [CMake] cmake-gui on windows and qt5 dlls

[Lectem]

Right, as mentionned by Craig Scott, a script might do the trick ? Just a 
cmake-gui.bat that calls cmake-gui.exe should work.

De : Robert Maynard
Envoyé le :lundi 14 août 2017 15:24
À : Craig Scott
Cc : Clément Gregoire; CMake
Objet :Re: [CMake] cmake-gui on windows and qt5 dlls

More importantly symlinks are restricted to administrator accounts
only in Windows Vista/7/8. Windows 10 with Developer Mode activated
allows none-elevated accounts to create symlinks.

This is important as CMake does ship non-installer windows binaries.

On Mon, Aug 14, 2017 at 9:00 AM, Craig Scott <craig.sc...@crascit.com> wrote:
>
>
> On Mon, Aug 14, 2017 at 9:05 PM, Clément Gregoire <lec...@gmail.com> wrote:
>>
>> Wouldn't it be possible to move it to a subfolder with the DLLs and put a
>> link next to cmake and ccmake? Executables look for DLLs in their directory
>> and it wouldn't pollute the PATH
>
>
> Symlinks are available on NTFS filesystems from Vista onwards. If the user
> installed CMake on, say, a FAT filesystem instead or on an old XP box (CMake
> appears to still try to support that), then symlinks wouldn't be available
> from what I can make out. One could potentially use a forwarding script of
> some kind though to achieve essentially the same thing.
>
>
>> I personally like to be able to launch it through the command line, it is
>> faster than looking for it and then browse for the folder.
>>
>>
>> Le lun. 14 août 2017 à 11:48, Craig Scott <craig.sc...@crascit.com> a
>> écrit :
>>>
>>> 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
>>> <ch.ehrlic...@gmx.de> 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/opensource/opensource.html
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://public.kitware.com/mailman/listinfo/cmake
>>>
>>>
>>>
>>>
>>> --
>>> 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 Kitw

Re: [CMake] cmake-gui on windows and qt5 dlls

[Konstantin Tokarev]

14.08.2017, 16:01, "Craig Scott" :
> On Mon, Aug 14, 2017 at 9:05 PM, Clément Gregoire  wrote:
>> Wouldn't it be possible to move it to a subfolder with the DLLs and put a 
>> link next to cmake and ccmake? Executables look for DLLs in their directory 
>> and it wouldn't pollute the PATH
>
> Symlinks are available on NTFS filesystems from Vista onwards. If the user 
> installed CMake on, say, a FAT filesystem instead or on an old XP box (CMake 
> appears to still try to support that), then symlinks wouldn't be available 
> from what I can make out. One could potentially use a forwarding script of 
> some kind though to achieve essentially the same thing.

This tool might be useful

https://github.com/chocolatey/shimgen

>
>> I personally like to be able to launch it through the command line, it is 
>> faster than looking for it and then browse for the folder.
>>
>> Le lun. 14 août 2017 à 11:48, Craig Scott  a écrit :
>>> 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/opensource/opensource.html

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/mailman/listinfo/cmake
>>>
>>> --
>>> 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
>
> --
> 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


-- 
Regards,
Konstantin
-- 

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 

Re: [CMake] cmake-gui on windows and qt5 dlls

[Robert Maynard]

More importantly symlinks are restricted to administrator accounts
only in Windows Vista/7/8. Windows 10 with Developer Mode activated
allows none-elevated accounts to create symlinks.

This is important as CMake does ship non-installer windows binaries.

On Mon, Aug 14, 2017 at 9:00 AM, Craig Scott  wrote:
>
>
> On Mon, Aug 14, 2017 at 9:05 PM, Clément Gregoire  wrote:
>>
>> Wouldn't it be possible to move it to a subfolder with the DLLs and put a
>> link next to cmake and ccmake? Executables look for DLLs in their directory
>> and it wouldn't pollute the PATH
>
>
> Symlinks are available on NTFS filesystems from Vista onwards. If the user
> installed CMake on, say, a FAT filesystem instead or on an old XP box (CMake
> appears to still try to support that), then symlinks wouldn't be available
> from what I can make out. One could potentially use a forwarding script of
> some kind though to achieve essentially the same thing.
>
>
>> I personally like to be able to launch it through the command line, it is
>> faster than looking for it and then browse for the folder.
>>
>>
>> Le lun. 14 août 2017 à 11:48, Craig Scott  a
>> écrit :
>>>
>>> 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/opensource/opensource.html

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/mailman/listinfo/cmake
>>>
>>>
>>>
>>>
>>> --
>>> 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
>
>
>
>
> --
> 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
-- 

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 

Re: [CMake] cmake-gui on windows and qt5 dlls

[Craig Scott]

On Mon, Aug 14, 2017 at 9:05 PM, Clément Gregoire  wrote:

> Wouldn't it be possible to move it to a subfolder with the DLLs and put a
> link next to cmake and ccmake? Executables look for DLLs in their directory
> and it wouldn't pollute the PATH
>

Symlinks are available on NTFS filesystems from Vista onwards. If the user
installed CMake on, say, a FAT filesystem instead or on an old XP box
(CMake appears to still try to support that), then symlinks wouldn't be
available from what I can make out. One could potentially use a forwarding
script of some kind though to achieve essentially the same thing.


I personally like to be able to launch it through the command line, it is
> faster than looking for it and then browse for the folder.
>
> Le lun. 14 août 2017 à 11:48, Craig Scott  a
> écrit :
>
>> 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/
>>> opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/cmake
>>>
>>
>>
>>
>> --
>> 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
>
>


-- 
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

Re: [CMake] cmake-gui on windows and qt5 dlls

[Clément Gregoire]

Wouldn't it be possible to move it to a subfolder with the DLLs and put a
link next to cmake and ccmake? Executables look for DLLs in their directory
and it wouldn't pollute the PATH

I personally like to be able to launch it through the command line, it is
faster than looking for it and then browse for the folder.

Le lun. 14 août 2017 à 11:48, Craig Scott  a
écrit :

> 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/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>>
>
>
>
> --
> 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
-- 

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

Re: [CMake] cmake-gui on windows and qt5 dlls

[Craig Scott]

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/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>



-- 
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