It is what it is. My position has always been that integrating
everything under CMake would be a tricky process requiring potentially
hundreds of hours to get exactly right on all the platforms we care
about, and the resulting system would likely be more fragile than the
autotools build system. T
On Fri, 04 Mar 2011 09:43:28 -0600
DRC wrote:
> No, you are misunderstanding how CMake works. CMAKE_CL_64 is never set
> except when CMake detects a 64-bit version of CL, the Visual C++
> compiler. That variable is not meant to be used to detect a 64-bit
> version of GCC.
>
Well that makes it
No, you are misunderstanding how CMake works. CMAKE_CL_64 is never set
except when CMake detects a 64-bit version of CL, the Visual C++
compiler. That variable is not meant to be used to detect a 64-bit
version of GCC.
On 3/4/11 8:32 AM, Pierre Ossman wrote:
> On Thu, 03 Mar 2011 06:42:19 -0600
I'm really quite distressed at all of these modifications, because I
spent quite a bit of time making sure that the CMake build system for
Windows worked well on MinGW + GMake, MinGW64 + GMake, Visual C++ 32-bit
and 64-bit + NMake, Visual C++ 32-bit + Visual Studio IDE, and MinGW
cross-compiled on
That is why I had not reported it yet. I am not sure which Xserver
base DRC is compiling against. Using his binaries has been
convenient for testing the beta releases. Ensures I am seeing the
same issues most others are...
Robert
On 03/04/2011 09:3
Just thought of something:
it may be because I am using X.Org X Server 1.6.5 and not the 1.7 like
mentioned in the bug fixed report... I'll try to use 1.7, but I'm not
sure I will be able to do it.
On 04/03/11 15:33, Robert Goley wrote:
>I am still getting the same result as well. I am usi
I am still getting the same result as well. I am using Debian Lenny
with Windows XP. Both are using DRC's binaries.
Robert
On 03/04/2011 05:36 AM, Tim Ooms wrote:
Hi,
I just installed the pre-beta and it looks like the autorepeat (Bug
Tracker it
On Thu, 03 Mar 2011 06:42:19 -0600
DRC wrote:
> Argh. There was a reason why I did things the way I did. What you just
> did below breaks the build on MinGW64. CMAKE_CL_64 is only set for
> Visual C++.
>
Comments and/or descriptive commit messages help. ;)
It's been restored in r4322.
Rgds
BUILDING.txt documents that it is necessary to pass
-DCMAKE_BUILD_TYPE=Release to CMake when building with the NMake
generator, so that is sufficient in my mind. It's become habit for me
to add that whenever I'm doing a Windows build.
On 3/4/11 5:37 AM, Pierre Ossman wrote:
> On Thu, 03 Mar 2011
On Thu, 03 Mar 2011 06:59:21 -0600
DRC wrote:
> Please note that CMake, when used with Visual C++ and NMake, will always
> set the default build type to Debug, so it always has to be overridden
> on the command line (see BUILDING.txt.) Setting the default
> CMAKE_BUILD_TYPE to Release, per below
Hi,
I just installed the pre-beta and it looks like the autorepeat (Bug
Tracker item #3036098) is still not working with tigervnc Xvnc linux
server and tigervnc windows client.
When I try to use the autorepeat this appears in the logs (just like the
original bug report)
[mi] mieqEnequeue: out-
On 03/03/2011 09:34 PM, Sebastiaan Breedveld wrote:
Hi,
Here is another patch. It adds a -resolutions argument with a list of
resolutions to add to the default list:
Xvnc -resolutions "1264x900 1400x1500"
Of course this is a more flexible approach than specifying only 1 with
the -geometry. A
12 matches
Mail list logo
