On 10/27/10 8:04 AM, Peter Åstrand wrote: > 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: > > 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?
We can argue theoreticals all day and night, but as the one who's down here in the trenches slinging the code, I can tell you that the devil is always in the details. Implementing the Windows build should have been a lot more straightforward than it was. I'm not saying that porting the Unix build to CMake is impossible-- I'm just saying that I expect it to take a lot more time than it took to do the Windows build system. Most of that will be spent tweaking and testing. Just taking the issue of LJT in isolation, look at it this way-- the Windows build of LJT was very tricky, but that's just one platform. What we're talking about here is not just getting LJT to build in CMake on one platform but on dozens. Every platform that needs to be supported with LJT has to be specifically accounted for, and we were able to borrow a lot of the autotools code for doing that from libjpeg/SIMD. If you wanted to greatly simplify the problem of porting our Unix build to CMake, the most obvious way to do it would be to consider using the pre-built libraries from the libjpeg-turbo project -- or to make the assumption that the user will download and build LJT from source -- rather than embedding our own version of it. That would allow us to separate the issue of building LJT from the issue of building TigerVNC. This makes sense for other reasons, too, such as the fact that Fedora and other distributions are replacing their "system libjpeg" with libjpeg-turbo. > 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... We've been through all of this before. Using autotools is unsupportable in a Windows environment, so if we want to support that platform, we must use another build system. However, what I'm saying is that I don't necessarily think that the Windows build system should dictate the direction of the Unix build system. I believe that they are separate problems and that we should only consider unifying them if it is of practical, not theoretical, benefit. How would you propose to build Xvnc with CMake? Xvnc is based on X.org, which requires autotools in order to build. Building Xvnc with CMake was never an option. Building VNCViewer on Unix with CMake is possible. However, I just wonder whether what we end up with is harder to support than two separate build systems. At the very least, implementing a CMake build system on Unix is going to be a lot more difficult (and thus costly) of a project than implementing the Windows build system. > My opinion is that we should really try to avoid multiple build systems. > It's a pain, we tried this with TightVNC. Yes, but you were using Visual C++ projects, which are a lot harder to support. Besides, why do you care as long as it works? We already really have two build systems-- MinGW and Unix. The fact that both of these systems are implemented using autotools does not free us from the obligation of maintaining both build systems and making sure that they both work. I don't see that anything has changed there. It's still up to the Windows developers to ensure that the Windows build system is maintained, and it's still up to the Unix developers to ensure that the Unix build system is maintained. If you're not actively developing code on Windows, then why do you care what system we use to make our lives easier, as long as your product build still works? The only overlap between the Unix and Windows builds is in the libraries under common/, and with the exception of libjpeg-turbo, the rest of the CMake scripts in that directory are dead simple to maintain -- and the libjpeg-turbo CMake script is cribbed from the upstream project, so it's simple to maintain as well. Thus, what are you really left with? All of the CMake complexity is under the win/ directory, and there is no way that that could be shared with Unix anyhow. The real question of complexity is: which is more complex, using autotools for Unix and CMake for Windows or using CMake for both? My opinion is that using CMake for both is more complex, because CMake requires a lot more code to handle platform-specific stuff. Once we remove the Windows build from autotools, then the only area in which both systems will be implemented is under common/. I don't see why that's a big deal. > 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. Let's just start with basics like finding the X11 includes/libraries and go from there. There are a lot of built-in functions in autotools (handling of man pages, making source distributions, etc. etc.) that CMake doesn't have, and that's one of the reasons why configure.ac is "only" 224 lines long. When I look at that file, what I'm imagining in my head is how many lines of CMake script would be required to do the same thing. It's a lot more than 224, I assure you. ------------------------------------------------------------------------------ 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
