chippo
January 24th, 2007, 01:52 AM
I've made my first commit into subversion (ain't it a cool package name)! Viva!
There are changes to some OpenTNL Makefiles to allow the propagation of variables from the top level make to sub-makes. This is to make it easier to build the Win32 version.
Just to remind you, the procedure to get, patch and compile OpenTNL (assuming you have legacy-2 SVN sources already checked out) is:# First check out OpenTNL
cvs -z9 -d:pserver:anonymous@opentnl.cvs.sourceforge.net:/cvsroot/opentnl co -P tnl
# then patch 'em
cd tnl
patch -p0 < ../PATH-TO-LEGACY-2-SVN-SOURCES/libtnl_patch.diff
# To compile the Linux version
make clean
make
# To compile the Win32 version
make clean
make CXX=i586-pc-mingw32-g++ CC=i586-pc-mingw32-gcc AR=i586-pc-mingw32-ar EXTRALIBS=-lwsock32
I did check that I didn't break the Linux make. This new patch also includes smitemeister's gcc 4 fixes and my testprof fix.
One anti-feature I introduced with these changes, is that OpenTNL will no longer build on a system whose 'ar' doesn't include 'ranlib' functionality. Such systems are old, and certainly none of them would be able to compile legacy. If there was any hope of OpenTNL accepting my patches, then I'd try harder to still support such ancient systems.
Cheers,
chip
There are changes to some OpenTNL Makefiles to allow the propagation of variables from the top level make to sub-makes. This is to make it easier to build the Win32 version.
Just to remind you, the procedure to get, patch and compile OpenTNL (assuming you have legacy-2 SVN sources already checked out) is:# First check out OpenTNL
cvs -z9 -d:pserver:anonymous@opentnl.cvs.sourceforge.net:/cvsroot/opentnl co -P tnl
# then patch 'em
cd tnl
patch -p0 < ../PATH-TO-LEGACY-2-SVN-SOURCES/libtnl_patch.diff
# To compile the Linux version
make clean
make
# To compile the Win32 version
make clean
make CXX=i586-pc-mingw32-g++ CC=i586-pc-mingw32-gcc AR=i586-pc-mingw32-ar EXTRALIBS=-lwsock32
I did check that I didn't break the Linux make. This new patch also includes smitemeister's gcc 4 fixes and my testprof fix.
One anti-feature I introduced with these changes, is that OpenTNL will no longer build on a system whose 'ar' doesn't include 'ranlib' functionality. Such systems are old, and certainly none of them would be able to compile legacy. If there was any hope of OpenTNL accepting my patches, then I'd try harder to still support such ancient systems.
Cheers,
chip