I am definitely in favor of using CMake for Windows builds. As to whether we should adopt it for the Unix build (minus Xvnc), I think further study is warranted. There are definite advantages to having a unified Unix/Windows build system, and architecturally, using CMake for both seems like the "right" thing to do. However, our autotools build system is rather complex and has a lot of O/S-specific elements, and I don't yet know enough about how host detection, etc. works in CMake to say whether we could make the transition cleanly. At minimum, I think that porting the Unix build to CMake will be a lot more difficult than porting the Windows build, and we may discover that the complexity of the resulting system overshadows any architectural advantage we gained through unification. At the very least, I think that if we decide to port the Unix build to CMake, we should tackle the Windows build first and then use that as a springboard for porting the Unix build in the long term (perhaps even post-1.1.)
You make a good point that MinGW can still be used with CMake, and in fact this is a much more usable solution on a native Windows machine than MinGW with autotools (autotools is the primary thing that causes the TigerVNC build to be unusably slow on Windows systems-- MinGW in isolation performs quite well.) Thus, even if we continue to maintain autotools for building the Unix code, there should be no reason to maintain autotools as a Windows build system anymore. I have been spending the last few weeks learning CMake and now have the TurboVNC Windows code base successfully building with it. It is a really solid system. When you use the MSVC IDE generators, it produces a comprehensive set of IDE projects that do exactly what IDE developers would expect. When you use the NMake generator, you can do everything from the command line. There was a little tweaking involved, but way less tweaking than is required to use autotools. Things generally "just work." 64-bit builds work beautifully, as do things like generating installers, etc. I can build upon much of this work to add a CMake system for TigerVNC/Windows, and I stand ready to do so, but since I'm not getting paid a salary to work on TigerVNC, I am seeking financial sponsorship for the effort (if anyone is interested in sponsoring it, please contact me off-list.) The ultimate deliverable will be an automated build system that generates binary packages for Linux, Mac, and Windows, and creating this new Windows build system is a critical prerequisite for me to start looking at more sexy enhancements to the Windows code, such as making WinVNC perform decently. DRC On 10/5/10 9:58 AM, Adam Tkac wrote: > On Thu, Sep 30, 2010 at 01:49:57PM -0400, Robert Goley wrote: >> Hmm... That may be my problem. I have been trying to build >> against 7.5 or the git repo. I haven't tried 7.4 since before the >> TLS stuff was officially added. I will try 7.4 again and post my >> results. Noticed the typo in the last email. I meant TigerVNC of >> course.... > > Hello all, > > let me put my two cents in. > > Finally I agree we should not use MinGW for building on Windows, this is > my major cons against MinGW: > > 1. There is problem with MinGW upstream, they have too strict > patch-accepting policy. Known example is my "CLSID_ActiveDesktop" > patch which is currently needed to build winvnc4 on Windows via MinGW. > In future we might hit this problem again which is not so nice. > Note I don't say MinGW's policy is bad, it simply is as is. However > occasional TigerVNC developers need to use custom patched MinGW build > system and I'm sure it's not so easy for middle-experienced Windows > developer who is not familiar with GNU build system to get it working. > > 2. This is purely subjective point, I don't like MinGW on Windows > much. In my opinion it simply doesn't fit into Windows style and I > prefer to use for example Visual Studio debugger, etc. > > I checked scons and cmake build systems and in my opinion cmake is the > right tool for us. With cmake I'm able to generate Makefiles on Linux > and use standard Linux tools, like gcc, make and gdb. On Windows > I'm able to generate VS project files and then use standard tools, > like msvc + headers + libs and VS's debugger. Note it's also possible > to generate MinGW makefiles on Windows so people who like MinGW won't > suffer from this change. CMake is far more flexible for our style of > development than GNU build chain. > > Note about Xvnc compilation. It's true we cannot use CMake for it. > However common/rfb/librfb.a can be compiled via CMake and then > Xvnc (with X.Org's GNU build system) can be linked against it. This > means we will maintain only unix/xserver/hw/Makefile.am. > > In my opinion we should consider to use CMake instead of GNU build > chain as our primary build system in 1.1. If I understand correctly > Darrell is also for CMake but I would like to hear opinion of Peter > and Pierre. > > My vote is +1 for CMake in TigerVNC 1.1. > > Regards, Adam > >>> Me too! That is why I'm willing to work on the CMake system. I haven't >>> yet been able to successfully build the Windows code myself, except for >>> just VNCViewer (which is painful because of all the MinGW dependencies.) >>> >>> As far as building on Lenny, I'm surprised that using build-xorg doesn't >>> work for you. That method, when used with the Xorg 7.4 code base, >>> should be backward compatible all the way back to RHEL 4 and its >>> contemporaries (Ubuntu 6, etc.) >>> >>> On 9/30/10 8:46 AM, Robert Goley wrote: >>>> I realize it would never completely replace autotools. I was just >>>> hoping for wrapper that would work a bit better. I haven't had that >>>> much luck with compiling TigerVNC on Lenny yet. The client stuff works >>>> fine but even compiling the whole Xorg tree for dependencies has not >>>> worked yet... May have just been my frustration coming thru... The >>>> Windows platform is next on my list and history tells me it never plays >>>> nice (MSVC or MinGW). I really want to start working with TightVNC's >>>> TLS connections. I applaud the work all the developers have done and >>>> look forward to when I can actually get to use it. > > ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
