I've looked at SCons cursorily. The original reason why I started looking at CMake was that I'm a visualization guy, and CMake has a lot of traction in that community (that's where it came from originally.) More generally, however, my (perhaps incorrect) impression is that there seem to be more projects moving to CMake than SCons (including some heavy hitters, like KDE), and it seems that CMake is more Windows-friendly. I like the idea of users being able to generate Visual Studio project files and then use the Visual Studio IDE to compile their project if they so desire. Most Windows developers are comfortable with this model. Personally, I'm more of a command line guy, so I like using Makefiles, but this gives us the option to support both environments without supporting multiple build systems. I don't see any particularly compelling reason to move the Unix code off of autotools, so really what we're looking for is what provides the best solution for Windows native development. CMake is a self-contained executable, i.e. it doesn't require Python (which isn't available on Windows systems), and thus it seems to be the most straightforward solution. The common view is that it's also faster, for the same reason.
Interesting perspective here: http://www.scons.org/wiki/SconsVsOtherBuildTools#head-3d0faf3f1d4d3b73f31eaa0ba97d4df18a474369 On 9/29/10 3:11 PM, Robert Goley wrote: > I would be glad to see a better cross platform build system. I have > done some work with CMake in the past and with SCons. I found Scons to > be a better system overall. One of the big selling points of it for me > was that it literally replaced the native systems make command and > launched the compiler and linker directly instead of wrapping them. > This seemed to allow for better concurrent object compiling with > multiple processors/cores. I saw my compile times cut in have comparing > it to GNU make's -j option with the same number of processors. > > Have you looked into SCons at all? I know this is just my 2 cents but I > certainly would be willing to help with a SCons based build system. > What are your thoughts? > > Robert > > > On 09/29/2010 03:50 PM, DRC wrote: >> I've been getting my hands dirty with CMake in recent weeks, and I now >> firmly believe that's the way to go with respect to a Windows build >> system for TigerVNC. I don't propose replacing autotools (at least for >> now), but CMake allows one to generate their own build system based on >> NMake or Visual Studio projects or even MinGW, and it works with 64-bit. >> People can still use MinGW and autotools to build TigerVNC if they >> want, but this gives native Windows developers a viable option for >> working with our code that doesn't require compiler customizations. >> >> The intermediary step is for me to implement a CMake system for Windows >> builds of libjpeg-turbo, and adding the system to TigerVNC should be >> straightforward after this is done. >> >> Since this is currently unfunded work, I can't give a timeframe as to >> when I might be able to complete it, but I believe that it needs to be >> part of 1.1. >> >> >> On 9/16/10 4:15 AM, Adam Tkac wrote: >>> On Thu, Sep 16, 2010 at 03:14:02AM -0500, DRC wrote: >>>> Once I can successfully get a static build going on RHEL 4 (still having >>>> problems with the lack of gnutls_transport_set_global_errno), I'll look >>>> into these issues. libgcrypt and libgnutls are definitely not >>>> cross-compatible, so the -static switch to build-xorg will probably have >>>> to accommodate those libs as well as the others. >>>> >>>> I'm hoping that the new Xorg 7.5 patches you just checked in will >>>> eliminate the build issue I had previously that was preventing me from >>>> using Xorg 7.5. If so, I will generate a static Xvnc binary and look >>>> into linking statically with gnutls. I then want to try out the >>>> security features to make sure they behave like I expect, and I'll be >>>> cool with releasing the alpha at that point. >>>> >>>> What is the situation with respect to doing Windows builds? I have >>>> never successfully managed to build WinVNC. Did those patches ever make >>>> it into a release of MinGW? >>> My MinGW patch isn't accepted, yet. And I'm not sure if it will be >>> accepted: >>> https://sourceforge.net/mailarchive/message.php?msg_name=AANLkTikg0hAGpArLTqFSWn6IdSI5aNOwJk-3ZDl4rqrq%40mail.gmail.com >>> >>> I'm going to merge my "vcstudio_buildsys" branch to trunk so it should >>> be possible to build winvnc with both MSVC and MinGW. >>> >>> Regards, Adam >>> >>>> On 9/15/10 9:06 AM, Adam Tkac wrote: >>>>> Hello, >>>>> >>>>> as you might have seen I performed build-xorg improvements >>>>> and it is now possible to build Xvnc via those scripts. In my opinion >>>>> prebuilt Xvnc will be built with this script so it's good time to >>>>> discuss remaining issues. >>>>> >>>>> "Statically" linked Xvnc now contains references for following >>>>> libraries: >>>>> >>>>> $ readelf -a ./Xvnc |grep NEEDE >>>>> 0x0000000000000001 (NEEDED) Shared library: [libpam.so.0] >>>>> 0x0000000000000001 (NEEDED) Shared library: >>>>> [libgnutls.so.26] >>>>> 0x0000000000000001 (NEEDED) Shared library: >>>>> [libgcrypt.so.11] >>>>> 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] >>>>> 0x0000000000000001 (NEEDED) Shared library: [librt.so.1] >>>>> 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] >>>>> 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] >>>>> 0x0000000000000001 (NEEDED) Shared library: >>>>> [ld-linux-x86-64.so.2] >>>>> 0x0000000000000001 (NEEDED) Shared library: >>>>> [libpthread.so.0] >>>>> >>>>> Everything except libgnutls.so.26 is present on old systems (i.e. RHEL4& >>>>> friends) >>>>> so we must decide what to do with libgnutls. Although I'm not friend >>>>> of static linking it seems we have to link Xvnc statically against >>>>> libgnutls to avoid compatibility issues. >>>>> >>>>> I also created two patches which add -dridir and -xkbcompdir >>>>> parameters to Xvnc. Those parameters should be determined same way as >>>>> -fp parameter in vncserver script and passed to Xvnc. >>>>> >>>>> After vncserver gets improved UNIX code is ready for the alpha >>>>> release, in my opinion. >>>>> >>>>> Regards, Adam >>>>> >>>> ------------------------------------------------------------------------------ >>>> Start uncovering the many advantages of virtual appliances >>>> and start using them to simplify application deployment and >>>> accelerate your shift to cloud computing. >>>> http://p.sf.net/sfu/novell-sfdev2dev >>>> _______________________________________________ >>>> Tigervnc-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/tigervnc-devel >> ------------------------------------------------------------------------------ >> Start uncovering the many advantages of virtual appliances >> and start using them to simplify application deployment and >> accelerate your shift to cloud computing. >> http://p.sf.net/sfu/novell-sfdev2dev >> _______________________________________________ >> Tigervnc-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/tigervnc-devel > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Tigervnc-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/tigervnc-devel ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Tigervnc-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
