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
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
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
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
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
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
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
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
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
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
_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/
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
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
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
14 matches
Mail list logo