On Sat, Feb 12, 2011 at 02:22:41AM -0600, DRC wrote: > 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.
Xorg will be always built via autotools (as long as upstream X.Org uses it). There should be no problem to build Xvnc + libvnc.so via autotools and all other stuff (binaries, libs) via cmake. > 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. I successfully use CMake & Visual Studio 2008 Express to build all Windows stuff with all features. And I'm also using MS VStudio for debugging & testing on Windows. I will extend BUILDING.txt with information how to build GNUTLS support on Windows. However for development I prefer to use MinGW & autotools because it's easier for me to develop on my Linux workstation and use wine for basic testing. I would prefer to keep autotools scripts for windows version. However I agree to mark autotools scripts for Windows as obsolete. In my opinion for TigerVNC 1.1 we can live with this: Windows: CMake (preferred) + autotools (obsolete, might not work) UN*X: autotools only This way we can release 1.1 version soon and during 1.2 development we can completely remove autotools based buildsys. Your comments are welcomed. Regards, Adam -- Adam Tkac, Red Hat, Inc. ------------------------------------------------------------------------------ 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
