[CMake] Distinguish two header files with same name using cmake

2017-08-14 Thread d...@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

Re: [CMake] Distinguish two header files with same name using cmake

2017-08-14 Thread Alan W. Irwin
On 2017-08-14 15:33-0600 d...@ucar.edu 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

[CMake] cmake-gui on windows and qt5 dlls

2017-08-14 Thread 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

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

2017-08-14 Thread 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

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

2017-08-14 Thread 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

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

2017-08-14 Thread 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

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

2017-08-14 Thread 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

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

2017-08-14 Thread 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

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

2017-08-14 Thread 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

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

2017-08-14 Thread Konstantin Podsvirov
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-commits] CMake branch, master, updated. v3.9.1-461-g4ca8c08

2017-08-14 Thread Kitware Robot
_VERSION_MINOR 9) -set(CMake_VERSION_PATCH 20170814) +set(CMake_VERSION_PATCH 20170815) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

[cmake-developers] Windows symbolic links handling

2017-08-14 Thread Manu
Hello, Recently I migrated from cmake 2.8.12 to cmake 3.8 and FILE(TIMESTAMP ...) behaviour changed. Now it reports symbolic link timestamp instead of pointed file timestamp. Looking through CMake documentation, it seems I could workaround this issue using the command get_filename_component

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

2017-08-14 Thread Craig Scott
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

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

2017-08-14 Thread 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