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 >>> Tigervnc-devel@lists.sourceforge.net >>> 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 > Tigervnc-devel@lists.sourceforge.net > 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 Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
