cmake-gui on windows and qt5 dlls

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

cmake-gui on windows and qt5 dlls

Christian Ehrlicher
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
Reply | Threaded
Open this post in threaded view
|

Re: cmake-gui on windows and qt5 dlls

Craig Scott-3
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 <[hidden email]> 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

--

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
Reply | Threaded
Open this post in threaded view
|

Re: cmake-gui on windows and qt5 dlls

Lectem

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 <[hidden email]> 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 <[hidden email]> 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
--

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
Reply | Threaded
Open this post in threaded view
|

Re: cmake-gui on windows and qt5 dlls

Craig Scott-3


On Mon, Aug 14, 2017 at 9:05 PM, Clément Gregoire <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
--

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

--

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
Reply | Threaded
Open this post in threaded view
|

Re: cmake-gui on windows and qt5 dlls

Konstantin Tokarev


14.08.2017, 16:01, "Craig Scott" <[hidden email]>:
> On Mon, Aug 14, 2017 at 9:05 PM, Clément Gregoire <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 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
Reply | Threaded
Open this post in threaded view
|

Re: cmake-gui on windows and qt5 dlls

Robert Maynard
In reply to this post by Craig Scott-3
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 <[hidden email]> wrote:

>
>
> On Mon, Aug 14, 2017 at 9:05 PM, Clément Gregoire <[hidden email]> 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 <[hidden email]> 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
>>> <[hidden email]> 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 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
Reply | Threaded
Open this post in threaded view
|

Re: 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 : [hidden email]
Envoyé le :lundi 14 août 2017 15:24
À : [hidden email]
Cc : [hidden email]; [hidden email]
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 <[hidden email]> wrote:

> 

> 

> On Mon, Aug 14, 2017 at 9:05 PM, Clément Gregoire <[hidden email]> 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 <[hidden email]> 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

>>> <[hidden email]> 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 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
Reply | Threaded
Open this post in threaded view
|

Distinguish two header files with same name using cmake

dmh@ucar.edu
I have the following situation using cmake
1. Running windows 7
2. Both cygwin and visual studio (VS) community edition (version 14)
    installed.
3. I am building with visual studio as my compiler.
4. Cygwin has winsock2.h in /usr/include/w32api
    The VS community edition does not have winsock2.h
5. Note that some older (non community edition) versions of VS do have
    winsock2.h defined.
6. CHECK_INCLUDE_FILE("winsock2.h", HAVE_WINSOCK2_H) returns true
    because it is finding the cygwin version instead of the VS version.

The question is how do I see if the installed VS has winsock2.h defined
while ignoring any cygwin version.

The reason I need to know this is that the presence of winsock2.h in VS
is causing a conflict with another package (libcurl). I can work around
the conflict if I know if the VS installation has winsock2.h (or not).

I speculate that I need to prevent CMake from searching w32api.
I considered using CMAKE_REQUIRED_INClUDES to remove a directory
(/usr/include/w32api), but I can see no way to do that.

Suggestions?

--

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
Reply | Threaded
Open this post in threaded view
|

Re: Distinguish two header files with same name using cmake

Alan W. Irwin
On 2017-08-14 15:33-0600 [hidden email] wrote:

> I have the following situation using cmake
> 1. Running windows 7
> 2. Both cygwin and visual studio (VS) community edition (version 14)
>   installed.
> 3. I am building with visual studio as my compiler.
> 4. Cygwin has winsock2.h in /usr/include/w32api
>   The VS community edition does not have winsock2.h
> 5. Note that some older (non community edition) versions of VS do have
>   winsock2.h defined.
> 6. CHECK_INCLUDE_FILE("winsock2.h", HAVE_WINSOCK2_H) returns true
>   because it is finding the cygwin version instead of the VS version.
>
> The question is how do I see if the installed VS has winsock2.h defined while
> ignoring any cygwin version.
>
> The reason I need to know this is that the presence of winsock2.h in VS is
> causing a conflict with another package (libcurl). I can work around the
> conflict if I know if the VS installation has winsock2.h (or not).
>
> I speculate that I need to prevent CMake from searching w32api.
> I considered using CMAKE_REQUIRED_INClUDES to remove a directory
> (/usr/include/w32api), but I can see no way to do that.
>
> Suggestions?

CMake pays close attention to environment variables (e.g., PATH) when
finding what it thinks are system files.  See the documentation of
find_path, find_file, find_library, etc.  So make sure there are no
mentions of Cygwin locations in any of your enviroment variables to
reduce the chances that Cygwin locations contaminate your VS build.

Alan

__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________
--

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
Reply | Threaded
Open this post in threaded view
|

Re: cmake-gui on windows and qt5 dlls

Lectem
In reply to this post by Lectem
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.


2017-08-14 15:33 GMT+02:00 Lectem <[hidden email]>:

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 : [hidden email]
Envoyé le :lundi 14 août 2017 15:24
À : [hidden email]
Cc : [hidden email]; [hidden email]
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 <[hidden email]> wrote:

> 

> 

> On Mon, Aug 14, 2017 at 9:05 PM, Clément Gregoire <[hidden email]> 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 <[hidden email]> 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

>>> <[hidden email]> 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 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
Reply | Threaded
Open this post in threaded view
|

Re: cmake-gui on windows and qt5 dlls

Konstantin Podsvirov
Hello Clément Gregoire!

17.08.2017, 21:55, "Clément Gregoire" <[hidden email]>:

> 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 <[hidden email]>:
>> 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 <[hidden email]> wrote:
>>
>>>
>>
>>>
>>
>>> On Mon, Aug 14, 2017 at 9:05 PM, Clément Gregoire <[hidden email]> 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 <[hidden email]> 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
>>
>>>>> <[hidden email]> 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 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 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
Reply | Threaded
Open this post in threaded view
|

Re: cmake-gui on windows and qt5 dlls

Craig Scott-3


On Fri, Aug 18, 2017 at 5:05 AM, Konstantin Podsvirov <[hidden email]> wrote:
Hello Clément Gregoire!

17.08.2017, 21:55, "Clément Gregoire" <[hidden email]>:
> 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)

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:


--
Craig Scott
Melbourne, Australia

--

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
Reply | Threaded
Open this post in threaded view
|

Re: cmake-gui on windows and qt5 dlls

Craig Scott-3


On Fri, Aug 18, 2017 at 6:23 AM, Craig Scott <[hidden email]> wrote:


On Fri, Aug 18, 2017 at 5:05 AM, Konstantin Podsvirov <[hidden email]> wrote:
Hello Clément Gregoire!

17.08.2017, 21:55, "Clément Gregoire" <[hidden email]>:
> 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)

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:


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

--

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