On 2/12/11 12:55 AM, Pierre Ossman wrote: > We want less bundled stuff, not more. Better we do a nice writeup > (possibly with helper scripts) on how to build GnuTLS on Windows.
Building it with MinGW is a no-brainer (although it takes a while, due to the slowness of MSYS autotools.) I built GnuTLS/libgcrypt/libtasn1/libgpg-error entirely from source with MinGW using --enable-static, installed into c:\GnuTLS, and then used that installation to build TigerVNC with MinGW (the latter procedure is documented in BUILDING.txt.) Building GnuTLS with Visual C++ is impossible, as far as I can tell, but it would be nice if it weren't. IMHO, the GnuTLS feature will be a second-class citizen on Windows until it can be built with Visual C++ (both 32-bit and 64-bit.) >> They are useful for cross-compiling (mingw as cross-compiler) - in >> fact, they were the only way for me to get an working windows viewer >> with GNU TLS support. >> > > We have a working prototype patch for building everything using CMake. > I'm currently crosscompiling the Windows stuff on Linux using CMake > (and the OS X stuff ;)). The plan is to do the transition after 1.1 as > there is a high risk of fallout. I'm a little fuzzy -- are you successfully using the CMake build system, as it is currently checked into SVN, to cross-compile Windows binaries, or did you have to add to it to make it work? And ugh. Yeah, I fully expect that switching Unix build systems will break most of what I just spent 35 hours doing. I understand the utility of switching everything to CMake in the long term, but in the short term, I can't afford to spend another week cleaning up build system idiosyncrasies for free like I did last week. I am going to suggest strongly that, in conjunction with moving to a unified CMake system, we remove our in-tree version of libjpeg-turbo and start sourcing LJT from upstream (or, in the case of Fedora, simply building against the system version, since libjpeg-turbo is the default JPEG library on that system now.) That will at least remove some of the fallout. I'm not ready to switch libjpeg-turbo entirely to CMake and don't generally see the utility of that (in fact, I like the fact that it uses autotools for Unix, since Unix developers are more familiar with that and since the upstream libjpeg code uses it.) As far as TigerVNC is concerned, I agree that CMake is the better long-term choice, particularly since we're heading toward a single-source viewer. I just fully expect the transition to be painful. Integrating it with build-xorg, in particular, is going to be a bear, since Xorg will still have to be built with autotools. In the meantime, it would still be nice to get rid of as much automake cruft as possible, to avoid confusion. It goes back to the principle of reducing the permutations so we can make sure that the permutations we really want to support get tested. If people are still using autotools for Windows, we need to know why, because it probably means something is broken in the CMake system. ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
