Re: [Flightgear-devel] configuration info (svn part)
Wow, what a debate. This is a reply to an early post in this thread. On 2/5/10 6:21 PM, Martin Spott wrote: Jari Häkkinen wrote: Actually I think subversion support in terrasync should be removed altogether or fixed. If removed then all svn checks could be removed. Oh my, could you _please_ stop this litany ? One posting of this sort per day should really be enough, two or more are a nuisance. According to my experience you're trying to make people throw the baby out with the bath water, which is not appropriate here. Well, I am only trying to suggest improvements to the code/build environment. I think this is the first time I actually suggest a feature to be thrown out. I remember trying to convince developers to remove dependencies on PLIB parts that are implicitly stated to not being used according to the fg build instructions. I have suggested that some code should be conditionally built (i.e. by doing make check). I had a few more posts but my hope and intent is that my postings actually improves fg. Nae, sorry Martin I have something more to say about terragear and subversion. I posted my previous message with a few things in mind 1) Document for other newcomers (I been around for one year soon but still consider me a fg code beginner since I only look at the code occasionally) that there are some strange features wrt subversion and terragear. They might catch this thread through their favourite search engine. 2) I wanted to report the bug (oups there I used the nasty word) in terrasync ... it locks directories. I gave a reference to another posting where I think it was clear that the issue was not being fixed by the father of the baby. 3) Also, on my machine with subversion development libs the configuration script fails out of the box. Therefore I attached a patch for others to use or ignore. 4) I also acknowledged the fact that Geoffs was right but I wanted to highlight that the terragear flaw is still valid. Geoffs response to my posting explains why he is not experiencing the issues I see. If we were to drop every feature which _might_ occasionally have a malfunction here or there, then we would end up with having no FlightGear at all, The problem is that the terrasync issue happens almost every time I run fg but then of course terragear is started each time I run fg (even for short tests). There are many directories to sync each time terrasync stars. I don't want to drop features and I am crazy enough to run terragear with the current subversion flaw ... hoping it will be fixed some day. Am I the only one using subversion built-in terragear? Cheers, Jari -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration info
Hi Jari, I read _LOUDLY_ your 'fear' that changing anything to do with the 'svn' may cause some unwanted change... but feel this is totally unfounded... It seems my explanation that changing - AC_CHECK_HEADERS([svn_client.h glut.h]) - to - AC_CHECK_HEADERS([svn_client.h]) would change NOTHING about the test for 'svn_client.h' yes/no FAILED to get through... You need to carefully check the references of AC_CHECK_HEADERS([header-file-list] [, action-if-found [, action-if-not-found]]) to SEE that the 'header-file-list' are EACH treated completely separately. They would 'share' the 'action-if-found', and 'action-if-not-found' if any were given, but in this case the default actions are used, so are separate... It is _NOT_ a case of if one fails, they all fail. As stated, if you had looked in the config.log, you would see that each test is done independently of the results of any previous test in the 'list'... That is the test, as is, would generate BOTH - 1. $ac_cv_header_svn_client_h = yes|no 2. $ac_cv_header_glut_h = yes|no But I have had more time to write, and test a BETTER patch attached that :- (a) does NOT change the svn_client.h lines ;=((, (b) avoids having to change tests/gl-info.cxx, (c) now includes the different check for the MAC. It seems that autoconf is smart enough to ignore the 'glut.h' listed in - AC_CHECK_HEADERS([svn_client.h glut.h]) once a specific later AC_CHECK_HEADERS([GL/glut.h],... is given, that contains an 'action-if-found' ;=() so I leave that line UNCHANGED, and only add this new check... And if you have removed all glut.h tests in your local configure.ac, then that is fine. It certainly means your tests/gl-info will also fail unless your GLUT/glut.h defines HAVE_GLUT_H... as would tests/test-env-map.cxx... And I hope your other 'svn' changes also make it into CVS... You had a hand in changing this 1998 Steve Baker file from .c to .cxx just recently, probably to get it to compile in the MAC. And at that time this 'HAVE_GLUT_H' was added - by Erik? Likewise to tests/test-env-map.cxx... I note the ONLY other file in the source that calls glutInit() is utils/Modeller/3dconvert.cxx and it has been commented out of the Makefile.am! So indeed another option is to REMOVE gl-info.cxx AND test-env-map.cxx from the compile (the Makefile.am), like 3dconvert.cxx... A grep for glutInit seems to indicate these are the ONLY 3 files in the FG source that still use glutInit... I would prefer my nice patch, but since fgfs no longer uses glut, maybe the REMOVE option is best ;=)) Of course there is SG - simgear/source/simgear/screen/TestRenderTexture.cpp which I had a hand in modifying relatively recently to compile and run in WIN32, and it has no protective #ifdef HAVE_GLUT_H, or HAVE_GL_GLUT_H... and thus the SG configure.ac does NOT contain a GL/glut.h, nor GLUT/glut.h, test... To be clear this is NOTHING about 'svn', and will NOT effect anything related to how 'svn' is compiled into fgfs for terrasync use... It is about, as the subject states, providing 'good' configuration information only... HTH, and NOT cause further confusion ;=)) Regards, Geoff. attached: fg200-diff02.patch On Thu, 2010-02-04 at 20:17 +0100, Jari Häkkinen wrote: On 2/4/10 6:16 PM, Geoff McLane wrote: Hi Jari, HOW? I have nothing against your patch, actually I have thrown away the check for glut.h completely in my local configure.ac. The check for glut.h is not needed. On my machine (Mac OS X 10.6) the AC_CHECK_HEADERS([svn_client.h glut.h]) always fail and in consequence the failure will trigger command line use in terrasync as stated in configure.ac after the AC_CHECK_HEADERS if test x$ac_cv_header_svn_client_h != xyes; then echo TerraSync will shell out for command line subversion svn_LIBS= svn_CPPFLAGS= else ... While I am writing this I realize that one of course need development libs for svn to pass the AC_CHECK_HEADERS so I suppose my statement was not perfectly accurate. I have the devlibs for svn installed and I actually go further in my local change of configure.ac and look for several svn libs: ... else echo TerraSync will use integrated subversion library AC_SEARCH_LIBS(svn_client_checkout, svn_client-1) + AC_SEARCH_LIBS(svn_delta_version, svn_delta-1) + AC_SEARCH_LIBS(svn_diff_version, svn_diff-1) + AC_SEARCH_LIBS(svn_ra_initialize, svn_ra-1) + AC_SEARCH_LIBS(svn_pool_create_ex, svn_subr-1) + AC_SEARCH_LIBS(svn_wc_version, svn_wc-1) svn_LIBS=$LIBS svn_CPPFLAGS=$CPPFLAGS AC_SUBST(svn_LIBS) and build a terrasync with builtin subversion calls. This is not really a good thing since terrasync with builtin subversion calls behaves badly when terrasync is interrupted during subversion calls. An issue acknowledge by Alex Perry in http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25662.html Again, the patch is valid I just wanted to highlight the fact that it
Re: [Flightgear-devel] configuration info
On 2/5/10 4:04 PM, Geoff McLane wrote: Hi Jari, I read _LOUDLY_ your 'fear' that changing anything to do with the 'svn' may cause some unwanted change... but feel this is totally unfounded... Yes, I agree. My bad. I added your checks to my configure.ac. Jari -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration info (svn part)
On 2/5/10 4:04 PM, Geoff McLane wrote: But I have had more time to write, and test a BETTER patch attached that :- (a) does NOT change the svn_client.h lines ;=((, (a) should be changed, I agree with your original proposal. Actually I think subversion support in terrasync should be removed altogether or fixed. If removed then all svn checks could be removed. And I hope your other 'svn' changes also make it into CVS... I attach my suggested svn related changes to configure.ac for reference for other new builders of fg. Note, apply the patch cautiously since having svn calls in terrasync may lock the terrasync-WC directories in some cases (with fairly high probability). Maybe there should be a check for APR but I suppose that if svn-devel package are installed then also apr will be available. Geoff, how do you make it through the svn check in configure.ac or really building terrasync? Jari Index: configure.ac === RCS file: /var/cvs/FlightGear-0.9/source/configure.ac,v retrieving revision 1.166 diff -u -p -r1.166 configure.ac --- configure.ac5 Feb 2010 05:40:15 - 1.166 +++ configure.ac5 Feb 2010 16:40:26 - @@ -787,10 +803,9 @@ fi dnl Check for Subversion library support save_LIBS=$LIBS save_CPPFLAGS=$CPPFLAGS -LIBS= +LIBS=`apr-1-config --link-ld` CPPFLAGS=-I/usr/include/subversion-1 `apr-1-config --includes` -AC_CHECK_LIB(svn_client-1, svn_client_checkout3) -AC_CHECK_HEADERS([svn_client.h glut.h]) +AC_CHECK_HEADERS([svn_client.h]) if test x$ac_cv_header_svn_client_h != xyes; then echo TerraSync will shell out for command line subversion svn_LIBS= @@ -798,6 +813,11 @@ if test x$ac_cv_header_svn_client_h != else echo TerraSync will use integrated subversion library AC_SEARCH_LIBS(svn_client_checkout, svn_client-1) + AC_SEARCH_LIBS(svn_delta_version, svn_delta-1) + AC_SEARCH_LIBS(svn_diff_version, svn_diff-1) + AC_SEARCH_LIBS(svn_ra_initialize, svn_ra-1) + AC_SEARCH_LIBS(svn_pool_create_ex, svn_subr-1) + AC_SEARCH_LIBS(svn_wc_version, svn_wc-1) svn_LIBS=$LIBS svn_CPPFLAGS=$CPPFLAGS AC_SUBST(svn_LIBS) -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration info (svn part)
Jari Häkkinen wrote: Actually I think subversion support in terrasync should be removed altogether or fixed. If removed then all svn checks could be removed. Oh my, could you _please_ stop this litany ? One posting of this sort per day should really be enough, two or more are a nuisance. According to my experience you're trying to make people throw the baby out with the bath water, which is not appropriate here. If we were to drop every feature which _might_ occasionally have a malfunction here or there, then we would end up with having no FlightGear at all, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration info (svn part)
Martin Spott wrote: Oh my, could you _please_ stop this litany ? One posting of this sort per day should really be enough, two or more are a nuisance. According to my experience you're trying to make people throw the baby out with the bath water, which is not appropriate here. which, BTW, doesn't mean that I'm against having a fix to clean up open connections and/or pending SVN locks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration info (svn part)
Hi Jari, Geoff, how do you make it through the svn check in configure.ac or really building terrasync? I don't have any problems ;=)) utils/TerraSync/ terrasync builds without ANY problems in my 64-bit Ubuntu 8.04... I do _NOT_ have the svn library, nor svn_client.h installed, but of course do have runtime svn version 1.5.1 (r32289), and rsync version 3.0.4, protocol version 30, so assume fgfs would shell out, IF NEED BE... But I _NEVER_ use TerraSync! It is abhorrent to me that fgfs should need to download 'scenery' to my machine, on the fly, as it is, putting it somewhere... UGH! But to be sure, the concept of 'terrasyncing' is good, for those who want to use it, and should be continued, and fixed if there are problems, but for me, like 'real' piloting, I prefer to make sure I have all the maps, oops I mean scenery, BEFORE I go there ;=)) I have downloaded, and installed 100% of the current scenery 1.0.1, and will do the same as each new build is done... HDD space is really cheap these days... Or I could burn my own DVDs, or better still toss a few bucks to Curt and get the DVD set by mail... As simple as that ;=)) Regards, Geoff. PS: I hope this post is NOT classified as part of any 'litany' ;=() -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration info
On Wed, 2010-02-03 at 08:47 -0700, John Denker wrote:
There is a little script to collect that information:
http://www.av8n.com/fly/fgfs/barf
Thanks John for your 'barf' script. I modified
it to suit my Ubuntu environment. My script
is at :-
http://geoffair.net/tmp/fgfs-info
In it I noted you run tests/gl-info, and
to my surprise this produced the output :-
GL Utility Toolkit (glut) was not found on this system.
which is CRAZY since I _DO_ have 'glut' installed!
freeglut3 2.4.0-6
freeglut3-dev 2.4.0-6
glutg33.7-25
glutg3-dev3.7-25
libglut3 3.7-25
libglut3-dev 3.7-25
Looking in src/Include/config.h showed the reason.
'HAVE_GLUT_H' was undefined! So that led me back
to configure.ac...
Yes, it does a check for [... glut.h], and of course
does NOT find this... But tests/gl-info.cxx
does NOT include glut.h, but includes
GL/glut.h (if not __APPLE__)...
It also checks for, and finds glutGetModifiers,
and adds the library - result: -lglut
So adding a test to configure.ac -
AC_CHECK_HEADERS(GL/glut.h)
which added -
#define HAVE_GL_GLUT_H 1
to src/Include/config.h...
So one would have to ask how did you compile
gl-info? ... Of course I also then changed
'HAVE_GLUT_H' to 'HAVE_GL_GLUT_H' in gl-info.cxx
source, then all is honky dorey...
I hope someone will take the time to fix
this in FG CVS... Attached below is my
diff... Of course this would need to be
further adjusted for __APPLE__
Or maybe just remove the -
#ifdef HAVE_GLUT_H
completely from tests/gl-info.cxx,
since fgfs defaults to using the osgviewer.
Does fgfs use GL/glut.h anywhere else
but in this tests/gl-info??? 'glut.h' appears
only mentioned in the old (2005) docs-mini/
README.mingw...
HTH
Geoff.
PS: My info is at -
http://geoffair.net/tmp/tempinfo.txt
There also seems some problems with
tests/alcinfo, but have yet to look into
this...
attached: fg200-diff01.patch
Index: configure.ac
===
RCS file: /var/cvs/FlightGear-0.9/source/configure.ac,v
retrieving revision 1.165
diff -u -r1.165 configure.ac
--- configure.ac 23 Jan 2010 22:26:30 - 1.165
+++ configure.ac 4 Feb 2010 12:40:29 -
@@ -790,7 +790,7 @@
LIBS=
CPPFLAGS=-I/usr/include/subversion-1 `apr-1-config --includes`
AC_CHECK_LIB(svn_client-1, svn_client_checkout3)
-AC_CHECK_HEADERS([svn_client.h glut.h])
+AC_CHECK_HEADERS([svn_client.h])
if test x$ac_cv_header_svn_client_h != xyes; then
echo TerraSync will shell out for command line subversion
svn_LIBS=
@@ -815,6 +815,7 @@
dnl Checks for header files.
AC_HEADER_STDC
+AC_CHECK_HEADERS(GL/glut.h)
AC_CHECK_HEADERS( \
fcntl.h getopt.h malloc.h memory.h stdlib.h sys/param.h sys/stat.h \
sys/time.h sys/timeb.h unistd.h windows.h values.h )
Index: tests/gl-info.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/tests/gl-info.cxx,v
retrieving revision 1.1
diff -u -r1.1 gl-info.cxx
--- tests/gl-info.cxx 8 Dec 2009 09:48:01 - 1.1
+++ tests/gl-info.cxx 4 Feb 2010 12:40:30 -
@@ -24,7 +24,7 @@
# include GLUT/glut.h
#else
# include GL/gl.h
-# ifdef HAVE_GLUT_H
+# ifdef HAVE_GL_GLUT_H
# include GL/glut.h
# endif
#endif
@@ -65,7 +65,7 @@
int main ( int argc, char **argv )
{
-#ifdef HAVE_GLUT_H
+#ifdef HAVE_GL_GLUT_H
glutInit( argc, argv ) ;
glutInitDisplayMode ( GLUT_RGB | GLUT_DOUBLE | GLUT_DEPTH ) ;
glutCreateWindow( You should never see this window! ) ;
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration info
The suggested patch to configure.ac may have unwanted side effects in that if may trigger a build of a terrasync binary with builtin subversion calls rather than use of external svn calls. The problem with terrasync using builtin subversion calls is that the current implementation does don't behave well when terrasync is interrupted (svn working copies ends up in locked state). This has been recently discussed on the mailing list. Jari On 2/4/10 2:44 PM, Geoff McLane wrote: On Wed, 2010-02-03 at 08:47 -0700, John Denker wrote: There is a little script to collect that information: http://www.av8n.com/fly/fgfs/barf Thanks John for your 'barf' script. I modified it to suit my Ubuntu environment. My script is at :- http://geoffair.net/tmp/fgfs-info In it I noted you run tests/gl-info, and to my surprise this produced the output :- GL Utility Toolkit (glut) was not found on this system. which is CRAZY since I _DO_ have 'glut' installed! freeglut3 2.4.0-6 freeglut3-dev 2.4.0-6 glutg33.7-25 glutg3-dev3.7-25 libglut3 3.7-25 libglut3-dev 3.7-25 Looking in src/Include/config.h showed the reason. 'HAVE_GLUT_H' was undefined! So that led me back to configure.ac... Yes, it does a check for [... glut.h], and of course does NOT find this... But tests/gl-info.cxx does NOT includeglut.h, but includes GL/glut.h (if not __APPLE__)... It also checks for, and finds glutGetModifiers, and adds the library - result: -lglut So adding a test to configure.ac - AC_CHECK_HEADERS(GL/glut.h) which added - #define HAVE_GL_GLUT_H 1 to src/Include/config.h... So one would have to ask how did you compile gl-info? ... Of course I also then changed 'HAVE_GLUT_H' to 'HAVE_GL_GLUT_H' in gl-info.cxx source, then all is honky dorey... I hope someone will take the time to fix this in FG CVS... Attached below is my diff... Of course this would need to be further adjusted for __APPLE__ Or maybe just remove the - #ifdef HAVE_GLUT_H completely from tests/gl-info.cxx, since fgfs defaults to using the osgviewer. Does fgfs useGL/glut.h anywhere else but in this tests/gl-info??? 'glut.h' appears only mentioned in the old (2005) docs-mini/ README.mingw... HTH Geoff. PS: My info is at - http://geoffair.net/tmp/tempinfo.txt There also seems some problems with tests/alcinfo, but have yet to look into this... attached: fg200-diff01.patch -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration info
Hi Jari, HOW? My patch separated the check for 'svn_client.h' from the check for 'glut.h'... I have no idea why these two checks were put together in the first place... they are nothing to do with each other... And if you checked the config.log you would see that these were always done as two separate, unrelated, checks... So really can NOT understand why you would suggest the patch would 'trigger a build of a terrasync binary' different to anything currently built... It does nothing more that putting #define HAVE_GL_GLUT_H 1 in Include/config.h Please read the patch again... Regards, Geoff. On Thu, 2010-02-04 at 17:08 +0100, Jari Häkkinen wrote: The suggested patch to configure.ac may have unwanted side effects in that if may trigger a build of a terrasync binary with builtin subversion calls rather than use of external svn calls. The problem with terrasync using builtin subversion calls is that the current implementation does don't behave well when terrasync is interrupted (svn working copies ends up in locked state). This has been recently discussed on the mailing list. Jari On 2/4/10 2:44 PM, Geoff McLane wrote: On Wed, 2010-02-03 at 08:47 -0700, John Denker wrote: There is a little script to collect that information: http://www.av8n.com/fly/fgfs/barf Thanks John for your 'barf' script. I modified it to suit my Ubuntu environment. My script is at :- http://geoffair.net/tmp/fgfs-info In it I noted you run tests/gl-info, and to my surprise this produced the output :- GL Utility Toolkit (glut) was not found on this system. which is CRAZY since I _DO_ have 'glut' installed! freeglut3 2.4.0-6 freeglut3-dev 2.4.0-6 glutg33.7-25 glutg3-dev3.7-25 libglut3 3.7-25 libglut3-dev 3.7-25 Looking in src/Include/config.h showed the reason. 'HAVE_GLUT_H' was undefined! So that led me back to configure.ac... Yes, it does a check for [... glut.h], and of course does NOT find this... But tests/gl-info.cxx does NOT includeglut.h, but includes GL/glut.h (if not __APPLE__)... It also checks for, and finds glutGetModifiers, and adds the library - result: -lglut So adding a test to configure.ac - AC_CHECK_HEADERS(GL/glut.h) which added - #define HAVE_GL_GLUT_H 1 to src/Include/config.h... So one would have to ask how did you compile gl-info? ... Of course I also then changed 'HAVE_GLUT_H' to 'HAVE_GL_GLUT_H' in gl-info.cxx source, then all is honky dorey... I hope someone will take the time to fix this in FG CVS... Attached below is my diff... Of course this would need to be further adjusted for __APPLE__ Or maybe just remove the - #ifdef HAVE_GLUT_H completely from tests/gl-info.cxx, since fgfs defaults to using the osgviewer. Does fgfs useGL/glut.h anywhere else but in this tests/gl-info??? 'glut.h' appears only mentioned in the old (2005) docs-mini/ README.mingw... HTH Geoff. PS: My info is at - http://geoffair.net/tmp/tempinfo.txt There also seems some problems with tests/alcinfo, but have yet to look into this... attached: fg200-diff01.patch -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration info
On 2/4/10 6:16 PM, Geoff McLane wrote: Hi Jari, HOW? I have nothing against your patch, actually I have thrown away the check for glut.h completely in my local configure.ac. The check for glut.h is not needed. On my machine (Mac OS X 10.6) the AC_CHECK_HEADERS([svn_client.h glut.h]) always fail and in consequence the failure will trigger command line use in terrasync as stated in configure.ac after the AC_CHECK_HEADERS if test x$ac_cv_header_svn_client_h != xyes; then echo TerraSync will shell out for command line subversion svn_LIBS= svn_CPPFLAGS= else ... While I am writing this I realize that one of course need development libs for svn to pass the AC_CHECK_HEADERS so I suppose my statement was not perfectly accurate. I have the devlibs for svn installed and I actually go further in my local change of configure.ac and look for several svn libs: ... else echo TerraSync will use integrated subversion library AC_SEARCH_LIBS(svn_client_checkout, svn_client-1) + AC_SEARCH_LIBS(svn_delta_version, svn_delta-1) + AC_SEARCH_LIBS(svn_diff_version, svn_diff-1) + AC_SEARCH_LIBS(svn_ra_initialize, svn_ra-1) + AC_SEARCH_LIBS(svn_pool_create_ex, svn_subr-1) + AC_SEARCH_LIBS(svn_wc_version, svn_wc-1) svn_LIBS=$LIBS svn_CPPFLAGS=$CPPFLAGS AC_SUBST(svn_LIBS) and build a terrasync with builtin subversion calls. This is not really a good thing since terrasync with builtin subversion calls behaves badly when terrasync is interrupted during subversion calls. An issue acknowledge by Alex Perry in http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25662.html Again, the patch is valid I just wanted to highlight the fact that it may lead to unwanted changes in the build process. Cheers, Jari My patch separated the check for 'svn_client.h' from the check for 'glut.h'... I have no idea why these two checks were put together in the first place... they are nothing to do with each other... And if you checked the config.log you would see that these were always done as two separate, unrelated, checks... So really can NOT understand why you would suggest the patch would 'trigger a build of a terrasync binary' different to anything currently built... It does nothing more that putting #define HAVE_GL_GLUT_H 1 in Include/config.h Please read the patch again... Regards, Geoff. On Thu, 2010-02-04 at 17:08 +0100, Jari Häkkinen wrote: The suggested patch to configure.ac may have unwanted side effects in that if may trigger a build of a terrasync binary with builtin subversion calls rather than use of external svn calls. The problem with terrasync using builtin subversion calls is that the current implementation does don't behave well when terrasync is interrupted (svn working copies ends up in locked state). This has been recently discussed on the mailing list. Jari On 2/4/10 2:44 PM, Geoff McLane wrote: On Wed, 2010-02-03 at 08:47 -0700, John Denker wrote: There is a little script to collect that information: http://www.av8n.com/fly/fgfs/barf Thanks John for your 'barf' script. I modified it to suit my Ubuntu environment. My script is at :- http://geoffair.net/tmp/fgfs-info In it I noted you run tests/gl-info, and to my surprise this produced the output :- GL Utility Toolkit (glut) was not found on this system. which is CRAZY since I _DO_ have 'glut' installed! freeglut3 2.4.0-6 freeglut3-dev 2.4.0-6 glutg33.7-25 glutg3-dev3.7-25 libglut3 3.7-25 libglut3-dev 3.7-25 Looking in src/Include/config.h showed the reason. 'HAVE_GLUT_H' was undefined! So that led me back to configure.ac... Yes, it does a check for [... glut.h], and of course does NOT find this... But tests/gl-info.cxx does NOT includeglut.h, but includes GL/glut.h (if not __APPLE__)... It also checks for, and finds glutGetModifiers, and adds the library - result: -lglut So adding a test to configure.ac - AC_CHECK_HEADERS(GL/glut.h) which added - #define HAVE_GL_GLUT_H 1 to src/Include/config.h... So one would have to ask how did you compile gl-info? ... Of course I also then changed 'HAVE_GLUT_H' to 'HAVE_GL_GLUT_H' in gl-info.cxx source, then all is honky dorey... I hope someone will take the time to fix this in FG CVS... Attached below is my diff... Of course this would need to be further adjusted for __APPLE__ Or maybe just remove the - #ifdef HAVE_GLUT_H completely from tests/gl-info.cxx, since fgfs defaults to using the osgviewer. Does fgfs useGL/glut.h anywhere else but in this tests/gl-info??? 'glut.h' appears only mentioned in the old (2005) docs-mini/ README.mingw... HTH Geoff. PS: My info is at - http://geoffair.net/tmp/tempinfo.txt There also seems some problems with tests/alcinfo, but have yet to look into this... attached: fg200-diff01.patch
Re: [Flightgear-devel] configuration info
On 02/03/2010 01:37 AM, Tim Moore wrote: What hardware and driver? A possible workaround is to comment out the conditional tests related to gl_FrontFacing in Shaders/default.frag and Shaders/mat-anim.frag. Tim Whoops, never mind. Try the Shaders/mat-anim.frag that I just checked into CVS data. I devine that the hardware is ATI... No need for divination. As always, configuration info is at http://www.av8n.com/fly/fgfs/barf.log There is a little script to collect that information: http://www.av8n.com/fly/fgfs/barf You might want to encourage people to use such a script when submitting bug reports. It obviates a lot of divination. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
