Hello, On Wed, Oct 20, 2010 at 05:27:03AM -0500, DRC wrote: > The build system has gotten completely out of control. It worked fine > in 2004 when we only had two platforms to support, but it isn't really > suitable for supporting as many diverse platforms as VirtualGL now > supports. I plan to replace it with CMake at some point, which will > address all of the issues below, but this is not likely to happen until > sometime next year. Ok, good to hear that!
> In the meantime, if there is a straightforward way to make GNU Make > return a non-zero status when a build fails in a subdirectory, I'll be > glad to add that patch. I don't know of a way to do this, however. > > As far as the libjpeg-turbo directory, you can set the LJTDIR and LJTLIB > make variables to specify an alternate location for libjpeg-turbo. For > instance: > > make LJTDIR=/usr/local LJTLIB=/usr/local/lib > > (the build system looks for the LJT include files in $LJTDIR/include.) Then, is virtualgl working only libjpeg-turbo statically linked? Can I dynamically link? > The only time that the build system tries to build both 64-bit and > 32-bit code is when you either do 'make install' or 'make dist' on a > 64-bit build. If you are just building the 64-bit code without > installing it or creating a release package, then the 32-bit code is not > built. Thus, all you really need to do is write your own > install/packaging script which builds and installs only the 64-bit code. > It shouldn't be necessary to patch the Makefile. Ok, I'll go that way. Thank you very much, Lluís. > On 10/20/10 3:57 AM, Lluís Batlle i Rossell wrote: > > Hello, > > > > sorry for not having tested the beta versions. > > > > As a packager for the NixOS GNU/Linux distribution, I noticed some build > > annoyances: > > > > - The 'make' command does not return a non-zero value, if something fails. > > - In x86_64-linux, as told in BUILDING.txt, now requires a 32-bit capable > > compiler. The whole Makefile assumes this. We don't plan to distribute > > 32-bit > > binaries in x86_64-linux, so we will have to patch Makefile. Could that > > be an > > option, for furture virtualgl releases? > > - The linking stages expect libjpeg-turbo in a special place and fail if > > it's > > not there: > > ... -ltjpeg /opt/libjpeg-turbo/lib64/libjpeg.a ... > > > > Once I work over those problems, I'll report back. > > > > Thank you very much for this great software, > > Lluís. > > > > On Wed, Oct 20, 2010 at 03:01:25AM -0500, DRC wrote: > >> Significant code changes since 2.2 beta1: > >> ========================================= > >> > >> [1] > >> Added VGL_SPOILLAST environment variable which, when set to 0, will > >> change the frame spoiling algorithm used for frames triggered by > >> glFlush() calls. This is necessary to make Ansoft HFSS display properly. > >> > >> [2] > >> Add compatibility mode to allow NetTest to communicate with older > >> versions (from VGL 2.1.x and prior.) > >> > >> [3] > >> Fix race condition in vglclient which would frequently cause an > >> "incorrect checksum for freed object" error when the client was shut > >> down via CTRL-C. This problem was reported only on OS X but could have > >> existed on other platforms as well. > >> > >> > >> Significant packaging changes since 2.2 beta1: > >> ============================================== > >> > >> [1] > >> Upgraded libjpeg-turbo to 1.0.1 > >> > >> ------------------------------------------------------------------------------ > >> Download new Adobe(R) Flash(R) Builder(TM) 4 > >> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly > >> Flex(R) Builder(TM)) enable the development of rich applications that run > >> across multiple browsers and platforms. Download your free trials today! > >> http://p.sf.net/sfu/adobe-dev2dev > >> _______________________________________________ > >> VirtualGL-Users mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > ------------------------------------------------------------------------------ > > Download new Adobe(R) Flash(R) Builder(TM) 4 > > The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly > > Flex(R) Builder(TM)) enable the development of rich applications that run > > across multiple browsers and platforms. Download your free trials today! > > http://p.sf.net/sfu/adobe-dev2dev > > _______________________________________________ > > VirtualGL-Users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > ------------------------------------------------------------------------------ > Download new Adobe(R) Flash(R) Builder(TM) 4 > The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly > Flex(R) Builder(TM)) enable the development of rich applications that run > across multiple browsers and platforms. Download your free trials today! > http://p.sf.net/sfu/adobe-dev2dev > _______________________________________________ > VirtualGL-Users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/virtualgl-users ------------------------------------------------------------------------------ Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev _______________________________________________ VirtualGL-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/virtualgl-users
