Thread: [Plib-devel] Updated configure script in CVS
Brought to you by:
sjbaker
From: Sebastian U. <ud...@ha...> - 2002-08-30 19:09:53
|
As a result of the relocation of the preprocessor instructions that include the OpenGL header files from ul.h to fnt.h, pui.h and ssg.h (see thread "To Steve: gl.h / glu.h in ul.h"), it is now possible to build JS, NET, SG, SL and UL without the presence of any OpenGL implementation. Therefore, I checked a new configure.in into CVS that allows one to build only certain PLIB subsystems by specifying certain --enable- / --disable- options (for details, refer to the output of ./configure --help). This way, to use the example from my last mail, one can for example build only SL and UL on a minimalistic UNIX system that lacks X11 and OpenGL in order to write a simple console MOD player program. The configure script determines automatically if OpenGL and/or GLUT are needed for the chosen setup and does not check for their presence (and does not complain in case they can't be found) if they are not needed, such as in the examplatic case where only UL and SL are built. Although the new configure script works fine for me, there is always a chance I messed something up. Please test it and if you run into trouble and/or think you've found a bug in the script, BY ALL MEANS report it ! Thanks, Sebastian |
From: Wolfram K. <w_...@rz...> - 2002-08-30 19:30:38
|
Hi, >As a result of the relocation of the preprocessor instructions that = include >the OpenGL header files from ul.h to fnt.h, pui.h and ssg.h=20 Unfortunately, this breaks MSVC compilation. If I understand correctly, Windows users do not really have advantages from your changes. Therefore I will simply roll back the changes inside #ifdef WIN32 if there is no opposition against this. Bye bye, Wolfram. |
From: Sebastian U. <ud...@ha...> - 2002-08-30 19:37:57
|
On Fri, 30 Aug 2002, w_...@rz... (Wolfram Kuss) wrote: > Date: Fri, 30 Aug 2002 21:39:15 +0200 > To: pli...@li... > From: w_...@rz... (Wolfram Kuss) > Reply-To: pli...@li... > Subject: Re: [Plib-devel] Updated configure script in CVS > > Hi, > > >As a result of the relocation of the preprocessor instructions that > >include the OpenGL header files from ul.h to fnt.h, pui.h and ssg.h > > Unfortunately, this breaks MSVC compilation. If I understand > correctly, Windows users do not really have advantages from your > changes. Therefore I will simply roll back the changes inside > #ifdef WIN32 > if there is no opposition against this. Not in general - but how about if you could explain to me *why* excactly MSVC fails to compile PLIB after my changes ? - Sebastian |
From: Wolfram K. <w_...@rz...> - 2002-08-30 20:18:07
|
Hi Sebastian, >Not in general - but how about if you could explain to me *why* excactly >MSVC fails to compile PLIB after my changes ? I will - tomorrow. At work, I have wrong options for cvs and it works and here at home I have correct options and it says: "cvs log: warning: unrecognized response `wol...@cv...'s password:=20 ' from cvs server" CVS itself works, I can connect to my own cvs server. Anyway, the error message was a missing ";" in gl.h. My gut feeling is this will cost lots of time to re-sort include files. Probably the clincher is the order in which windows.h is included. >- Sebastian Bye bye, Wolfram. |
From: Sebastian U. <ud...@ha...> - 2002-08-30 20:50:19
|
On Fri, 30 Aug 2002, w_...@rz... (Wolfram Kuss) wrote: > Date: Fri, 30 Aug 2002 22:16:52 +0200 > To: pli...@li... > From: w_...@rz... (Wolfram Kuss) > Reply-To: pli...@li... > Subject: Re: [Plib-devel] Updated configure script in CVS [...] > At work, I have wrong options for cvs and it works and here at home I > have correct options and it says: > > "cvs log: warning: unrecognized response > `wol...@cv...'s password: > ' from cvs server" > > CVS itself works, I can connect to my own cvs server. Well, that's not good at all - but for the meanwhile, I uploaded the zipped CVS snapshot from 22:30 o'clock German time for you here: http://www.ude.handshake.de/plib-3008-2230.zip By the way; Does the anonymous (pserver) access method work for you ? cvs -d:pserver:ano...@cv...:/cvsroot/plib login [Press return when prompted for password] cvs -z3 -d:pserver:ano...@cv...:/cvsroot/plib co plib > Anyway, the error message was a missing ";" in gl.h. > My gut feeling is this will cost lots of time to re-sort include > files. Probably the clincher is the order in which windows.h is > included. Then, the solution should be rather easy: In fnt.h, pui.h, ssg.h and ssgAux.h, try to move the block: #ifdef __APPLE__ # include <OpenGL/gl.h> # include <OpenGL/glu.h> #else # include <GL/gl.h> # include <GL/glu.h> #endif *after* the preprocesser statements that include the other PLIB header files. This way, ul.h and thus all the compatibility stuff has already been included when the OpenGL headers are processed. Please tell me if that helped. - Sebastian |
From: Norman V. <nh...@ca...> - 2002-08-30 21:04:01
|
Sebastian Ude> > Then, the solution should be rather easy: > > In fnt.h, pui.h, ssg.h and ssgAux.h, try to move the block: > > #ifdef __APPLE__ > # include <OpenGL/gl.h> > # include <OpenGL/glu.h> > #else > # include <GL/gl.h> > # include <GL/glu.h> > #endif > < nitpick > can't that just be #ifdef __APPLE__ # include <OpenGL/glu.h> #else # include <GL/glu.h> #endif AFAIK <GL/glu.h> #includes "gl.h" and <GL/glut.h> #includes "glu.h" < /nitpick > trying-to-minimze-compile-times'ly yr's Norman |
From: Sebastian U. <ud...@ha...> - 2002-08-30 21:33:46
|
On Fri, 30 Aug 2002, nh...@ca... (Norman Vine) wrote: > Date: Fri, 30 Aug 2002 17:03:54 -0400 > To: <pli...@li...> > From: nh...@ca... (Norman Vine) > Reply-To: pli...@li... > Subject: Re: [Plib-devel] Updated configure script in CVS [...] > < nitpick > > > can't that just be > > #ifdef __APPLE__ > # include <OpenGL/glu.h> > #else > # include <GL/glu.h> > #endif > > AFAIK > <GL/glu.h> #includes "gl.h" and > <GL/glut.h> #includes "glu.h" > > < /nitpick > > > trying-to-minimze-compile-times'ly yr's Well, the examples from the red and the green book always #include *both* gl.h and glu.h (in this order). The question is if it is said anywhere that glu.h *must* include gl.h. Steve ? - Sebastian |
From: Steve B. <sjb...@ai...> - 2002-08-30 23:33:16
|
Sebastian Ude wrote: >>can't that just be >> >>#ifdef __APPLE__ >># include <OpenGL/glu.h> >>#else >># include <GL/glu.h> >>#endif >> >>AFAIK >><GL/glu.h> #includes "gl.h" and >><GL/glut.h> #includes "glu.h" > Well, the examples from the red and the green book always #include *both* > gl.h and glu.h (in this order). Yes. > The question is if it is said anywhere that glu.h *must* include gl.h. I don't think I've seen that said anywhere - but a more significant question is "Why are we including glu.h at all?" I doubt we are using GLU functions anywhere in the core package - and it's just one more annoying dependancy we could avoid. So I think we just need: #include <GL/gl.h> ...however, some of the example programs *do* use glu.h functions - so the problem has to be resolved there. However, it *is* defined that glut.h includes both gl.h and glu.h - so since (IIRC) we include glut.h in all of the examples and demos, we should be OK there too. I think the only file that's affected is ul.h - and didn't we just remove the #include <GL/gl*> from that file? ----------------------------- Steve Baker ------------------------------- Mail : <sjb...@ai...> WorkMail: <sj...@li...> URLs : http://www.sjbaker.org http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net http://freeglut.sf.net http://toobular.sf.net http://lodestone.sf.net |
From: Sebastian U. <ud...@ha...> - 2002-08-30 23:56:56
|
On Fri, 30 Aug 2002, sjb...@ai... (Steve Baker) wrote: > Date: Fri, 30 Aug 2002 18:33:13 -0500 > To: pli...@li... > From: sjb...@ai... (Steve Baker) > Reply-To: pli...@li... > Subject: Re: [Plib-devel] OpenGL headers (was: Updated configure script > in CVS) [...] > > The question is if it is said anywhere that glu.h *must* include gl.h. > > I don't think I've seen that said anywhere - but a more significant > question is "Why are we including glu.h at all?" I doubt we are using > GLU functions anywhere in the core package - and it's just one more > annoying dependancy we could avoid. Good point, Steve. I checked it - the PLIB libraries are in deed entirely GLU-free. Hooray ! If we can keep the PLIB libraries GLU-free in the long run - which should not be a big problem as far as I can tell, but of course, you are the expert concerning these things - I don't see any reason why we should NOT get rid of the GLU dependancy. Thus, I am going to remove all occurances of "#include <GL/glu.h>" from the source and I will modify the build system of the main library (!) so that it no longer checks for libGLU. > So I think we just need: > > #include <GL/gl.h> I agree. > ....however, some of the example programs *do* use glu.h functions - so > the problem has to be resolved there. However, it *is* defined that glut.h > includes both gl.h and glu.h - [...] Excactly. > [...] so since (IIRC) we include glut.h in all of the examples and demos, we > should be OK there too. Yes. - Sebastian |
From: Steve B. <sjb...@ai...> - 2002-08-31 01:13:00
|
Sebastian Ude wrote: > Thus, I am going to remove all occurances of "#include <GL/glu.h>" from the > source and I will modify the build system of the main library (!) so that > it no longer checks for libGLU. Better make sure that the examples and demos *do* check - they may not be doing that right now because before your change, if PLIB was installed then so was GLU...so there was no need to test...but now there will be a need. ----------------------------- Steve Baker ------------------------------- Mail : <sjb...@ai...> WorkMail: <sj...@li...> URLs : http://www.sjbaker.org http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net http://freeglut.sf.net http://toobular.sf.net http://lodestone.sf.net |
From: Sebastian U. <ud...@ha...> - 2002-08-31 13:50:46
|
On Fri, 30 Aug 2002, sjb...@ai... (Steve Baker) wrote: > Date: Fri, 30 Aug 2002 20:13:05 -0500 > To: pli...@li... > From: sjb...@ai... (Steve Baker) > Reply-To: pli...@li... > Subject: Re: [Plib-devel] OpenGL headers (was: Updated configure script > in CVS) > > Sebastian Ude wrote: > > > Thus, I am going to remove all occurances of "#include <GL/glu.h>" from > > the source and I will modify the build system of the main library (!) > > so that it no longer checks for libGLU. > > Better make sure that the examples and demos *do* check - they may not be > doing that right now because before your change, if PLIB was installed > then so was GLU...so there was no need to test...but now there will be a > need. The examples did always check and as I said, I just removed the check from the configure.in of the main library. - Sebastian |
From: Julian F. <jul...@bt...> - 2002-08-31 00:09:11
Attachments:
ac_msg_notice.diff
|
Sebastian Ude wrote: > > Therefore, I checked a new configure.in into CVS that allows one to build > only certain PLIB subsystems by specifying certain --enable- / --disable- > options > ... > Although the new configure script works fine for me, there is always a > chance I messed something up. Please test it and if you run into trouble > and/or think you've found a bug in the script, BY ALL MEANS report it ! The "AC_MSG_NOTICE(...)" at the end of configure.in is not valid with autoconf 2.13: $ ./autogen.sh Running aclocal Running automake Running autoconf autoconf: Undefined macros: configure.in:399:AC_MSG_NOTICE( ====================================== Now you are ready to run './configure' ====================================== This leads on to an error when running "configure": here are the last few lines of its output: ... creating src/ssgAux/Makefile creating src/fnt/Makefile creating src/net/Makefile ./configure: 3813: Syntax error: word unexpected (expecting ")") The syntax error is in the "echo" command to print the message. This would have been the last command in "configure" anyway, so you can actually ignore the errors and carry on, but that does not make it OK, I'm sure you will agree. Perhaps you can use plain "echo" (or possibly an older message-printing macro like AC_MSG_RESULT) instead. Patch attached. Tested on CygWin with autoconf versions 2.13 and 2.53. - Julian |
From: Sebastian U. <ud...@ha...> - 2002-08-31 13:48:16
|
On Sat, 31 Aug 2002, jul...@bt... (Julian Foad) wrote: > Date: Sat, 31 Aug 2002 01:15:02 +0100 > To: pli...@li... > From: jul...@bt... (Julian Foad) > Reply-To: pli...@li... > Subject: Re: [Plib-devel] Updated configure script in CVS [...] > The "AC_MSG_NOTICE(...)" at the end of configure.in is not valid with > autoconf 2.13: > > $ ./autogen.sh > Running aclocal > Running automake > Running autoconf > autoconf: Undefined macros: > configure.in:399:AC_MSG_NOTICE( > ====================================== > Now you are ready to run './configure' > ====================================== > > This leads on to an error when running "configure": here are the last > few lines of its output: [...] > Perhaps you can use plain "echo" (or possibly an older message-printing > macro like AC_MSG_RESULT) instead. Patch attached. Tested on CygWin > with autoconf versions 2.13 and 2.53. > > - Julian Thanks for the report, Julian ! I replaced the AC_MSG_NOTICE by AC_MSG_RESULT in CVS. - Sebastian |