From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-07-11 19:41:48
|
Gentlemen, With Chris Purnell fixing his font binary compatibility problem, and with the renaming of the Windows static subdirectories, I would like to ask whether there is anything standing between us and Release Candidate 2. I think I was also told that the "configure" script would handle itself. John F. Fay joh...@eg... |
From: Bernhard K. <ber...@gm...> - 2003-07-12 18:32:52
|
On Fri, 11 Jul 2003, Fay John F Contr AAC/WMG wrote: > Gentlemen, > > With Chris Purnell fixing his font binary compatibility problem, and > with the renaming of the Windows static subdirectories, I would like to ask > whether there is anything standing between us and Release Candidate 2. I > think I was also told that the "configure" script would handle itself. No, the configure is not yet dealt with properly. I want to point to the two bug comments at the end for reference. It is common package practice that an official tarball for users to compile just builds and install by using the following commands: tar xvfz $PACKAGE.tar.gz cd $PACKAGE ./configure --prefix=/home/devel make make install The "autogen.sh" script is only of help for developers which are real CVS users and have the full GNU autoconfig toolsuite installed. Normal users don't have it installed, thus released package include everything to just being able to run ./configure;make . The "autogen.sh" script is nonetheless very useful, even in the tarball, because it contains all commands needed(and in order) to regenerate all GNU autoconfig files properly, which is not a trivial job if you don't know the correct order and which commands to execute. While I find it nice for people which use 56k modems that we safe nearly 200k of gzip'ed CVS checkout size/tarball size, I think sparing these 200k for a user download does not justify the hassle which users have if these 200k are missing. And even on a 56k modem, a 200k sync/download should not take too long, so I would be even ok to add them to the CVS repository, even if it's not quite "clean" to do so, but many projects, even gcc have the needed files in their CVS. Bernhard -------------------------------------------------------------------- [ freeglut-Bugs-766310 ] the configure script is missing in 2.0.0-rc1 Bugs item #766310, was opened at 2003-07-05 12:09 ---------------------------------------------------------------------- Comment By: Andrew P. Lentvorski, Jr. (bsder) Date: 2003-07-12 08:37 Please generate the configure script as part of the tarball. It would be even better if it were placed in CVS, too. Without this script, freeglut requires m4, automake, autoconf, and a bunch of non-standard automacros simply to compile. That basically prevents any non-Linux user from being able to build freeglut. ---------------------------------------------------------------------- Comment By: James Jones (puggles) Date: 2003-07-05 13:34 We either need to add this to a FAQ, or just generate the configure script; I've seen it done both ways, but the most common is to just generate the configure script. ---------------------------------------------------------------------- |
From: A. U. <ma...@da...> - 2003-07-12 18:57:08
|
Bernhard Kaindl <ber...@gm...> schrieb am 12 Jul 2003: > It is common package practice that an official tarball for users > to compile just builds and install by using the following commands: > > tar xvfz $PACKAGE.tar.gz > cd $PACKAGE > ./configure --prefix=/home/devel > make > make install I agree. > The "autogen.sh" script is only of help for developers which are > real CVS users and have the full GNU autoconfig toolsuite installed. > Normal users don't have it installed, thus released package include > everything to just being able to run ./configure;make . > > The "autogen.sh" script is nonetheless very useful, even in the > tarball, because it contains all commands needed(and in order) > to regenerate all GNU autoconfig files properly, which is not > a trivial job if you don't know the correct order and which > commands to execute. The 'proper way' to release the source for the users is to just do a 'make dist' (I think Steve pointed this out already), and let autoconf/automake decide which files to include in the distribution (of course, you need to mention all the source & header files in the Makefile.am, but we have to do that anyway...). Also, 'make distcheck' will automagically test if the package built this way compiles correctly. Currently, make dist is broken, I'll have a look at what needs to be changed to fix that. Also, on my machine, the depcomp & missing symlinks in the tarball are broken. I assume make dist will see to that. - Andreas |
From: A. U. <ma...@da...> - 2003-07-12 19:09:12
|
A. Umbach <ma...@da...> schrieb am 12 Jul 2003: > The 'proper way' to release the source for the users is to just do a 'make > dist' (I think Steve pointed this out already), and let autoconf/automake > decide which files to include in the distribution (of course, you need > to mention all the source & header files in the Makefile.am, but we have > to do that anyway...). Also, 'make distcheck' will automagically test > if the package built this way compiles correctly. Currently, make dist > is broken, I'll have a look at what needs to be changed to fix that. Oh, and if someone with a bit of autoconf (and perhaps libtool?) experience wants to give me a hand, I'm currently in #freeglut on irc.freenode.net - Andreas |
From: A. U. <ma...@da...> - 2003-07-12 20:15:35
|
A. Umbach <ma...@da...> schrieb am 12 Jul 2003: > The 'proper way' to release the source for the users is to just do a 'make > dist' (I think Steve pointed this out already), and let autoconf/automake > decide which files to include in the distribution (of course, you need > to mention all the source & header files in the Makefile.am, but we have > to do that anyway...). Also, 'make distcheck' will automagically test > if the package built this way compiles correctly. Currently, make dist > is broken, I'll have a look at what needs to be changed to fix that. Ok, after I got 'make dist' to work, i.e. it generated a redistributable freeglut-2.0.0.tar.gz that compiled and installed, I went a little further: What about dropping libfreeglut.so entirely, and just going for libglut.so? AFAIK the latest glut is 3.7, so why not just take over at 3.8? I changed lib_LTLIBRARIES from libfreeeglut.la to libglut.la, and bumped the version info in LDFLAGS to 3:8:0. I compiled a test app using Mesa-5.0's glut, installed freeglut, ran ldconfig, and voila, it worked. Then I recompiled using freeglut, uninstalled freeglut using make uninstall, reinstalled the mesa rpm's, reran ldconfig, and it still worked! Anything more we need? - Andreas |
From: A. U. <ma...@da...> - 2003-07-12 20:20:53
|
A. Umbach <ma...@da...> schrieb am 12 Jul 2003: > Ok, after I got 'make dist' to work, i.e. it generated a redistributable > freeglut-2.0.0.tar.gz that compiled and installed, I went a little further: Another thing: if you want to try the .tar.gz without updating from CVS and running make dist yourself, grab it from http://www.gltron.org/stuff/freeglut-2.0.0.tar.gz MSVC++ projects: I haven't had the time to check them and figure out which are the right ones, so I just included freeglut.dsp and freeglut.dsw, if there's more to add, just append them to EXTRA_DIST in freeglut/Makefile.am - Andreas |
From: Norman V. <nh...@ca...> - 2003-07-13 01:07:32
|
A. Umbach writes: > > A. Umbach <ma...@da...> schrieb am 12 Jul 2003: > > Ok, after I got 'make dist' to work, i.e. it generated a redistributable > > freeglut-2.0.0.tar.gz that compiled and installed, I went a little further: > > Another thing: if you want to try the .tar.gz without updating from CVS and > running make dist yourself, grab it from > > http://www.gltron.org/stuff/freeglut-2.0.0.tar.gz > > MSVC++ projects: I haven't had the time to check them and figure > out which are the right ones, so I just included freeglut.dsp and > freeglut.dsw, if there's more to add, just append them to EXTRA_DIST > in freeglut/Makefile.am I downloaded this and made necessary changes to enable building a statically linked freeglut with Cygwin and MingW32. < ./configure --disable-shared > I will work on the shared library support when I can find some time but IMHO not having this should not hold up the release < FWIW - I abhor libtool so ...> Other then the necesary tweaks to the Demo / Makefile.am's, some debugging instrumentation to the Demo / Fractal programs *** I also *changed* glut.h and configure.in **** The changes to glut.h should not affect non Win32 users but this *needs* to be tested with MSVC Note as is this will *NOT* LINK on anything but Cygwin or MingW but AFAIK all one should need to do is add the appropriate files for GL_LIBS=@@@@XXXXX@@@@ below I do not have a 'X' based system so I can not test this If someone on a 'nix' system gets this to work could they please add my changes into the CVS The tarball made with 'make dist' is at http://www.vso.cape.com/~nhv/files/freeglut/freeglut-2.0.0.tar.gz HTH Norman ===== following snipped from configure.in ===== case "${host}" in *-*-cygwin* | *-*-mingw32*) dnl Windows. AC_HAVE_HEADERS( GL/gl.h GL/glu.h ) AC_DEFINE([WIN32], 1, [Define for Win32 platforms]) CFLAGS="$CFLAGS -DWIN32" CXXFLAGS="$CXXFLAGS -DWIN32" AC_DEFINE([NOMINMAX], 1, [Define for Win32 platforms]) GL_LIBS="-lglu32 -lopengl32" X_LIBS="-luser32 -lgdi32 -lwinmm" ;; *-apple-darwin*) dnl Mac OS X dnl Checks for libraries. AC_PATH_XTRA GL_LIBS=@@@@XXXXX@@@@ AC_HAVE_HEADERS( GL/gl.h GL/glu.h GL/glx.h ) ;; *) dnl Checks for libraries. AC_PATH_XTRA AC_HAVE_HEADERS( GL/gl.h GL/glu.h GL/glx.h ) GL_LIBS = @@@@XXXXXXX@@@@ ;; esac |
From: Norman V. <nh...@ca...> - 2003-07-13 14:55:09
|
Ack.... in our header files we have constructs like #ifndef FREEGLUT_H #define FREEGLUT_H ..... #undef these **should** be something like #ifndef __FREEGLUT_H__ #define __FREEGLUT_H__ This causes uncountless grief trying to compile FlightGear where they have used GLUT_H as a configure variable :-( Could someone with write privlidge please change all of the header files to include the underscores I would but my source tree is currently completely torn apart and this *needs* to be done prior to release Thanks Norman |
From: Norman V. <nh...@ca...> - 2003-07-13 16:56:24
|
Hi all I am happy to report that with minor tweaking FlightGear compiles and runs with freeglut on Win2K MingW32 :-) For those not familiar with FlightGear this is a large cross-platform application > 100k LOC built on top of Steve's PLIB which makes extensive use of both glut and PLIB functionality The missing underscores in our header guards took a while to catch :-( The major work however was with the FGFS autconf files and this probably would not have been a problem if I was willing to rename libfreeglut.a libglut32.a, however I wanted to keep these separate and also to use #include <GL/freeglut.h> instead of <GL/glut.h> so as to be able to take advantage of the freeglut extensions with minimum impact on the source If anyone on another project using autoconf wants to do the same contact me off list and I can share the autoconf scripts I used One glitch I noticed right away between GLUT and freeglut behaviour is that the following code void toggleFullScreen (puObject *) { static int _saved_ww, _saved_wh; static bool _fullscreen = 0; _fullscreen = !_fullscreen; if (_fullscreen) { _saved_ww = (fgGetInt("/sim/startup/xsize")); _saved_wh = (fgGetInt("/sim/startup/ysize")); glutFullScreen(); fgReshape( glutGet(GLUT_WINDOW_WIDTH), glutGet(GLUT_WINDOW_HEIGHT) ); } else { glutReshapeWindow(_saved_ww,_saved_wh); fgReshape( _saved_ww, _saved_wh ); } } will toggle between a fullscreen undecorated window and a decorated window in GLUT but in freeglut this always keeps the window decorations. Also If started in gamemode then this tries to add the window decorations in freeglut < the decorations are 'ghosted' > whereas with GLUT this will actually make a functional fully decorated window. IMHO Fixing this will likely cause major upheaval in the way freeglut manages windows however and IMHO this is not sufficient to hold up a release, but should probably be a 'priority' for post release work FWIW I have a conference starting this evening so I probably won't get a chance to 'play' with freeglut again until next weekend Cheers Norman |
From: Norman V. <nh...@ca...> - 2003-07-13 15:13:49
|
Hi all. We should probably include the following or something similar in our examples :-) Note that with freeglut the window does appear contrary to what the code says. < this does not happen with real GLUT > This is with MingW32 on Win2k Cheers Norman /* From: Steve Baker <sb...@li...> Sender: ro...@fa... To: OPENGL-GAMEDEV-L <OPE...@fa...> Subject: Re: Win32 OpenGL Resource Page Date: Fri, 24 Apr 1998 07:33:51 -0800 */ #include <stdio.h> #include <stdlib.h> #include <GL/freeglut.h> void getPrints ( GLenum token, char *string ) { printf ( "%s = \"%s\"\n", string, glGetString ( token ) ) ; } void getPrint2f ( GLenum token, char *string ) { GLfloat f[2] ; glGetFloatv ( token, f ) ; printf ( "%s = %g,%g\n", string, f[0],f[1] ) ; } void getPrintf ( GLenum token, char *string ) { GLfloat f ; glGetFloatv ( token, &f ) ; printf ( "%s = %g\n", string, f ) ; } void getPrint2i ( GLenum token, char *string ) { GLint i[2] ; glGetIntegerv ( token, i ) ; printf ( "%s = %d,%d\n", string, i[0],i[1] ) ; } void getPrinti ( GLenum token, char *string ) { GLint i ; glGetIntegerv ( token, &i ) ; printf ( "%s = %d\n", string, i ) ; } int main ( int argc, char **argv ) { glutInit ( &argc, argv ) ; glutInitDisplayMode ( GLUT_RGB | GLUT_DOUBLE | GLUT_DEPTH ) ; glutCreateWindow ( "You should never see this window!" ) ; getPrints ( GL_VENDOR , "GL_VENDOR" ) ; getPrints ( GL_RENDERER , "GL_RENDERER" ) ; getPrints ( GL_VERSION , "GL_VERSION" ) ; getPrints ( GL_EXTENSIONS , "GL_EXTENSIONS" ) ; getPrinti ( GL_RED_BITS , "GL_RED_BITS" ) ; getPrinti ( GL_GREEN_BITS , "GL_GREEN_BITS" ) ; getPrinti ( GL_BLUE_BITS , "GL_BLUE_BITS" ) ; getPrinti ( GL_ALPHA_BITS , "GL_ALPHA_BITS" ) ; getPrinti ( GL_DEPTH_BITS , "GL_DEPTH_BITS" ) ; getPrinti ( GL_INDEX_BITS , "GL_INDEX_BITS" ) ; getPrinti ( GL_STENCIL_BITS, "GL_STENCIL_BITS" ) ; getPrinti ( GL_ACCUM_RED_BITS , "GL_ACCUM_RED_BITS" ) ; getPrinti ( GL_ACCUM_GREEN_BITS, "GL_ACCUM_GREEN_BITS" ) ; getPrinti ( GL_ACCUM_BLUE_BITS , "GL_ACCUM_BLUE_BITS" ) ; getPrinti ( GL_ACCUM_ALPHA_BITS, "GL_ACCUM_ALPHA_BITS" ) ; getPrinti ( GL_AUX_BUFFERS, "GL_AUX_BUFFERS" ) ; getPrinti ( GL_MAX_ATTRIB_STACK_DEPTH , "GL_MAX_ATTRIB_STACK_DEPTH" ) ; getPrinti ( GL_MAX_NAME_STACK_DEPTH , "GL_MAX_NAME_STACK_DEPTH" ) ; getPrinti ( GL_MAX_TEXTURE_STACK_DEPTH , "GL_MAX_TEXTURE_STACK_DEPTH" ) ; getPrinti ( GL_MAX_PROJECTION_STACK_DEPTH, "GL_MAX_PROJECTION_STACK_DEPTH" ) ; getPrinti ( GL_MAX_MODELVIEW_STACK_DEPTH , "GL_MAX_MODELVIEW_STACK_DEPTH" ) ; getPrinti ( GL_MAX_CLIP_PLANES , "GL_MAX_CLIP_PLANES" ) ; getPrinti ( GL_MAX_EVAL_ORDER , "GL_MAX_EVAL_ORDER" ) ; getPrinti ( GL_MAX_LIGHTS , "GL_MAX_LIGHTS" ) ; getPrinti ( GL_MAX_LIST_NESTING , "GL_MAX_LIST_NESTING" ) ; getPrinti ( GL_MAX_TEXTURE_SIZE , "GL_MAX_TEXTURE_SIZE" ) ; getPrint2i( GL_MAX_VIEWPORT_DIMS , "GL_MAX_VIEWPORT_DIMS" ) ; getPrintf ( GL_POINT_SIZE_GRANULARITY, "GL_POINT_SIZE_GRANULARITY" ) ; getPrint2f( GL_POINT_SIZE_RANGE , "GL_POINT_SIZE_RANGE" ) ; printf("Default values:\n\n"); getPrinti( GL_UNPACK_ALIGNMENT , "GL_UNPACK_ALIGNMENT" ) ; getPrinti( GL_UNPACK_ROW_LENGTH , "GL_UNPACK_ROW_LENGTH" ) ; getPrinti( GL_UNPACK_SKIP_PIXELS , "GL_UNPACK_SKIP_PIXELS" ) ; getPrinti( GL_UNPACK_SKIP_ROWS , "GL_UNPACK_SKIP_ROWS" ) ; getPrinti( GL_BLEND_SRC , "GL_BLEND_SRC" ) ; getPrinti( GL_BLEND_DST , "GL_BLEND_DST" ) ; return 0 ; } |
From: Steve B. <sjb...@ai...> - 2003-07-13 17:10:55
|
Norman Vine wrote: > Hi all. > > We should probably include the following or something > similar in our examples :-) > > Note that with freeglut the window does appear contrary to > what the code says. < this does not happen with real GLUT > Hmm - that program is something of a hack (I should know, I wrote it!). It's a handy command-line tool to print some interesting facts about the capabilities of your graphics card and it's drivers. For that to work, it has to create an OpenGL rendering context - but doesn't need to (and ideally, shouldn't) instanciate the window because that would cause a momentary 'flash' on the screen. In GLUT, you can do that if you do a glutCreateWindow and never enter glutMainLoop. That's because all actual window creation is postponed until glutMainLoop - although (weirdly) the rendering context is created up-front when you do the glutCreateWindow. Given freeglut's intention to eliminate the need to run glutMainLoop, I think it's better to create the window in the CreateWindow call. That's what the name of the function implies it'll do after all. This program also assumes that the rendering context created by glutCreateWindow is also the *current* rendering context when it exits - which GLUT doesn't explicitly guarantee. I would argue that this program has no right to assume that all of these things are the case (because the GLUT documentation promises none of them). It only works by luck and I should have no right to expect it to continue to work. It's worth mentioning this subtle distinction in the freeglut documentation, but I don't think we should attempt to fix it unless there are other good reasons to do so. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |