I've finished implementing a CMake build system for the libjpeg-turbo Windows code, and during the course of that project, I was able to gain a lot more experience with CMake in general. Based on what I've seen so far, it's my belief that porting the existing TigerVNC Unix build system is theoretically possible. However, the task would not be an easy one, primarily because of all of the platform-specific stuff in our autotools system. CMake is really good at certain things, such as supporting a variety of different build systems, but what it's not as good at is dealing with a lot of diverse platform configurations-- detecting various characteristics of Unix systems and reacting accordingly, for instance, requires more hacking than it does under autoconf. It also seems like I consistently ran into roadblocks trying to do things that should be straightforward, such as overriding the default compiler flags for a specific target and build type. Getting NASM to work right was also quite the chore. The price you pay for CMake's ability to support multiple build systems is that everything must be abstracted through its unique scripting interface, and if a feature isn't supported in that interface, it often becomes quite difficult to work around it. Thus, invoking custom tools and dealing with their dependencies, etc., can be very awkward.
I'm not meaning to demean CMake in any way. I'm just saying that it has different strengths and weaknesses than autotools. With autotools, the system is complex, prone to bizarre failures and incompatibilities, and not cross-platform-friendly, but it is very extensible (almost to a fault.) With CMake, the system is simple, but making it do what you want sometimes requires a lot of contortions (i.e. the burden of complexity shifts to the build scripts.) It required more obfuscation than I would have liked in order to get the Windows build of LJT working, and I'm concerned that trying to implement the Unix build system, as it stands now, would require quite a few more, making the resulting system hard to maintain. What I'm going to recommend, for now, is that I go ahead and finish implementing and stabilizing the CMake system for building the Windows code and that we use both systems side-by-side in TigerVNC 1.1. We could drop Windows support from autotools if we wanted to, because CMake supports MinGW builds (on native Windows as well as cross-compiled on Linux.) This would eliminate at least a bit of the complexity from the autotools system. Here's my basic reasoning-- most of the active development on this project is going to take place on Unix, so the Windows build system does not need to be as flexible, nor will it change nearly as often. If someone adds a file under autotools, assuming the file is needed on Windows as well, it will show up when we try to do an automated build, which will prompt us to add it to the CMake system as well. I guess that, at the end of the day, I don't think having an integrated cross-platform build system is worth the price of completely destabilizing the project. Perhaps post 1.1, we could start looking at moving specific platforms onto the CMake system and testing them one by one. At the moment, though, the thought of trying to port over everything that's in our autotools system all at once makes my head spin. DRC ------------------------------------------------------------------------------ Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
