Comments below:
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
I think you should take a look at the Scribus project and how it supports
CMake. From what I can tell at a quick glance, checking for "various
characteristics of Unix systems" is very straight forward: In
scribus-1.3.3.14/ConfigureChecks.cmake:
#check for libz using the cmake supplied FindZLIB.cmake
if(ZLIB_FOUND)
set(HAVE_LIBZ 1)
else(ZLIB_FOUND)
set(HAVE_LIBZ 0)
endif(ZLIB_FOUND)
...
check_include_files(fcntl.h HAVE_FCNTL_H)
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.
I can imagine that getting the Windows build of LJT was tricky, but if you
managed to solve that, haven't you solved the most difficult part already?
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
Short term, no problem. But long term... :
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.
From a Cendio perspective, we have an either-or approach. We are currently
building all UNIX parts as well as the Windows vncviewer using
Autotools+MinGW. Assuming CMake is an viable alternative, we want to
switch everything over to CMake, and remove the Autotools build system.
WinVNC is an exception, but it should be possible to build the UNIX
Xvnc+vncviewer as well ad the Windows vncviewer with CMake. Otherwise, I'm
not sure CMake is such a good idea at all...
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
My opinion is that we should really try to avoid multiple build systems.
It's a pain, we tried this with TightVNC.
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.
I'm surprised that you feel like this. The TigerVNC configure.ac is only
224 lines long and not that magic. It could probably be even shorter if we
get rid of the IRIX and LynxOS checks (anyone interested in that?). The
tests are fairly common; not much different from other OSS projects. I
would be surprised if a migration to CMake would be much more difficult
for TigerVNC than for other projects.
Regards,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping Phone: +46-13-21 46 00
------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
