Re: [Flightgear-devel] maketg and makefg scripts
Hi Arnt, Please reduce the unnecessary 'size' of your emails. Sometimes it takes many clicks to get to anything you MAY have added. Instead of adding _ALL_ that has been said, pick out a little of the relevant context, if needed, like I do... ;=)) IT WILL NOT 'SEE' PLIB UNLESS YOU PATCH configure.ac as detailed... ..ok, add a patches tree and PATCH-ALL and PATCH-* stanzas to your make*g-1.0.6's? ;o) Simple answer is NO! ;=)) I am expecting the patch to get into the git terragear-cs sometime SOON - at least I HOPE so... otherwise the current configure.ac will ONLY support simgear, osg, plib installed into a 'standard' path ;=(( So, NO, my scripts handle enough things already without this type of HOPEFULLY TEMPORARY 'patch' addition... And concerning DOUPD, this should ONLY be used AFTER the initial downloads and builds are done, when you really MEAN that you want a FULL update of everything. That is _AFTER_ a full successful build, and some time has passed. The scripts will always do the initial download/checkout/clone WITHOUT it... In fact, they are meant to be run repeatedly WITHOUT any parameters added. I do not even consider NOPAUSE a 'safe' option!!! You SHOULD always at least inspect the ./configure step results, and abort if something is MISSING... And ADDDEBUG will write the ./configure output to the LOG file, for even more careful inspection... = /opt/bygg/fg/simgear/source/simgear/timing/timestamp.cxx:79: undefined reference to `clock_gettime' ..still happening with your makefg-1.0.5. Not when I run it ;=() I have NO IDEA why you get this error building fgfs. Mine builds ok. You did not give enough output to know exactly what was happening, but when linking fgfs, which includes -lsgtiming, it also includes -lrt, which I think is the library that contains this function. ~$ ls -l /lib/librt* -rw-r--r-- 1 root root 35784 2008-09-12 16:15 /lib/librt-2.7.so but not sure. Is there a command to sort of 'dump' a library to know what it exports? That is dump an ascii export list, not a 'hex' dump, like xxd? But anyway, this does not show anything wrong with my makefg script that I can see... = lines, since I found that sometimes using one LONG line of 'apt-get update a b c...' seemed to MISS some packages in the list!!! Not sure why? ..could be related to whining about sudo apt-get install without (or before) chking whether those are necessary, try $basename --version style chks or dpkg -l |grep what ever your scripts needs. Again NO, it is NOT! In all my tests, it just seems to 'miss' some things in a long list of things, and never 'complains' about repeated invocations. I do not always use NOPAUSE, and often READ the last outputs before continuing... the reason the 'waits' were put there in the first place! Yes, something like dpkg -l | grep would also do it, but that is even MORE scripting. Thus in a way, sudo apt-get install 'item' _IS_ a simple check that the 'item' exists... = ..ln -s /bin/sh /bin/dash is standard Ubuntu practice? ~$ ls -l /bin/sh lrwxrwxrwx 1 root root 4 2008-08-16 17:27 /bin/sh - dash Do not know if it is 'standard', but it is certainly done on my system. From the list of TG executables, it seems you got these built. PHEW!!! Of course you are 'free' to install them where ever you like ;=)) just like you have done, amending INSTALL_DIR_TG=whatever/you/want Now comes the 'hard' part, and that is building scenery using these tools... HAVE FUN ;=)) Regards, Geoff. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] maketg and makefg scripts
On Thu, 19 Mar 2009 17:36:46 +0100, Geoff wrote in message 1237480606.6461.3.ca...@dell02: Hi Arnt, Please reduce the unnecessary 'size' of your emails. Sometimes it takes many clicks to get to anything you MAY have added. Instead of adding _ALL_ that has been said, pick out a little of the relevant context, if needed, like I do... ;=)) ..I'll try, this time too, I'm afraid I must file a motion to file an overlength reply. ;o) IT WILL NOT 'SEE' PLIB UNLESS YOU PATCH configure.ac as detailed... ..ok, add a patches tree and PATCH-ALL and PATCH-* stanzas to your make*g-1.0.6's? ;o) Simple answer is NO! ;=)) I am expecting the patch to get into the git terragear-cs sometime SOON - at least I HOPE so... otherwise the current configure.ac will ONLY support simgear, osg, plib installed into a 'standard' path ;=(( So, NO, my scripts handle enough things already without this type of HOPEFULLY TEMPORARY 'patch' addition... ..my idea is use the patch tree primarily for local event Live-DVD etc releases stuff, such as moving the default start-up from rwy...@ksfo in C172 C-FGFS to e.g. rw...@enzv in the sled behind Rudolf, and emergencies such as the TG configure.ac, and to test patches, not as a permanent fix to TG or FG. ..gnu patch also offers to remove or reverse already applied patches, which is handy when patches get into the git etc trees, and to help debug your own git etc trees. ;o) And concerning DOUPD, this should ONLY be used AFTER the initial downloads and builds are done, when you really MEAN that you want a FULL update of everything. ..this is no different from a fresh blank start with ./make*g and will produce exactly the same T|FG binaries as a repeat ./make*g DOUPD? That is _AFTER_ a full successful build, and some time has passed. The scripts will always do the initial download/checkout/clone WITHOUT it... ..ok. In fact, they are meant to be run repeatedly WITHOUT any parameters added. I do not even consider NOPAUSE a 'safe' ..no, but us messing around with it, will make it safer and a safe starting point for a release generator cron job. ;o) option!!! You SHOULD always at least inspect the ./configure step results, and abort if something is MISSING... ..yup, first step is make sure your make*g works for both Ubuntu and Debian, then flog some Fedora etc victims thru the same needle eye without trashing what we have working. And ADDDEBUG will write the ./configure output to the LOG file, for even more careful inspection... ..ah thanks, I got the idea this was meant to add debug stuff to the binary builds. ;o) = /opt/bygg/fg/simgear/source/simgear/timing/timestamp.cxx:79: undefined reference to `clock_gettime' ..still happening with your makefg-1.0.5. Not when I run it ;=() ..??? Another dash|bash thing??? You use dash or bash right there as /bin/sh??? (On building FG in that part of makefg?) I have NO IDEA why you get this error building fgfs. Mine builds ok. You did not give enough output to know exactly what was happening, but when linking fgfs, which includes -lsgtiming, it also includes -lrt, which I think is the library that contains this function. ..so we need my ./makefg ADDDEBUG logs. In my next FU here. ~$ ls -l /lib/librt* -rw-r--r-- 1 root root 35784 2008-09-12 16:15 /lib/librt-2.7.so but not sure. ..I have: a45:~# ls -l /lib/librt* -rw-r--r-- 1 root root 30624 Feb 28 00:15 /lib/librt-2.9.so lrwxrwxrwx 1 root root12 Mar 2 01:21 /lib/librt.so.1 - librt-2.9.so a45:~# Is there a command to sort of 'dump' a library to know what it exports? That is dump an ascii export list, not a 'hex' dump, like xxd? ..if not hexdump, od, ldd, libtool, unstr or pkg-config, search ideas? I'm pretty sure you don't want typelib-dump nor bn_dump, and I fairly sure about rawshark too: a...@a45:~ $ man -k lib |grep dump bn_dump (3ssl) - BIGNUM library internal functions typelib-dump (1) - show ORBit2 type library modules a...@a45:~ $ man -k dump |grep lib bn_dump (3ssl) - BIGNUM library internal functions rawshark (1) - Dump and analyze raw libpcap data typelib-dump (1) - show ORBit2 type library modules a...@a45:~ $ man typelib-dump a...@a45:~ $ ..freeze (1) - dump a process into a self-executing file? Or gmxdump (1) - makes binary files human readable? _Amazing_ pile of er, non-junk on my test box. :o) But anyway, this does not show anything wrong with my makefg script that I can see... ..so we'll see what my ./makefg ADDDEBUG logs says. = lines, since I found that sometimes using one LONG line of 'apt-get update a b c...' seemed to MISS some packages in the list!!! Not sure why? ..could be related to whining about sudo apt-get install without (or before) chking whether those are necessary, try $basename --version style chks or dpkg -l |grep what ever your scripts needs. Again NO,
Re: [Flightgear-devel] maketg and makefg scripts
On Tue, 17 Mar 2009 14:07:51 +0100, Geoff wrote in message
1237295271.6674.2.ca...@dell02:
Hi Arnt,
Without reviewing the maketg logs of the form templogNN.txt,
..doh! You still want my 1.0.2 logs?
No, but it will always help on some items, to be able
to 'see' the current log(s) if more errors. The 'log' you
included with your 3rd email, seems to be from using maketg
v 1.0.2??? The 'NN' number increments each time you use
maketg...
I have now put up versions 1.0.4 which -
(a) Outputs which version it is to the log, and date...
(b) Drops the lsb_release stuff, which I was NOT using anyway.
Get these, and _DELETE_ all others...
http://geoffair.net/tmp/maketg
http://geoffair.net/tmp/makefg
..thanks. :o)
Other matters...
And remember the script 'installs' the final TG executables
in $HOME/bin,
..sure? And not /opt/bygg/tg/install nor
/opt/bygg/tg/install/bin in my case???:
a...@a45:/opt/bygg/tg $ ll $HOME/bin
ls: cannot access /home/arnt/bin: No such file or directory
Yes, I AM SURE! The 'install' process CREATES directories
when they do not exist...
..funny, then I should be able to build in my /opt/bygg/*g/
trees and get the binaries into /home/arnt/bin, no?
Or, a dash bash bug? See below on your escape tests.
export PATH=${PATH}:$HOME/bin
You MUST change the script if you want them installed
elsewhere...
..ok, for my 2 (fg tg) trees, I will need
export PATH=${PATH}:/opt/bygg/fg/install/bin and
export PATH=${PATH}:/opt/bygg/tg/install/bin ?
Unh... NO!
1. Running FG:
=
If you 'really' wanted the 'fgfs' executable to be in
your path then you would need something like -
export PATH=${PATH}:/opt/bygg/fg/install/fgfs/bin
..actually, I prefer combine using the distro packaging system
(.deb in our case) and brlcad style naming to install and test
e.g. svn-fgfs-built-w-geoffs-maketg-with-bash-in-SG-from-git.
..but first, let's get your script working on my test box. ;o)
(32bit Debian Squeeze/Sid/unstable)
BUT this alone would NOT work, because 'fgfs' needs
access to the OSG shared libraries, which by the script, are
installed in /opt/bygg/fg/install/OpenSceneGraph/lib64
but there is a link created to it from -
/opt/bygg/fg/install/OpenSceneGraph/lib
So to be able to run fgfs from anywhere, which is the sole
reason for putting it in your PATH, then you would always need to
preceed it with -
~$ export LD_LIBRARY_PATH=/opt/bygg/fg/install/OpenSceneGraph/lib
~$ fgfs [OPTIONS]
or you could set up the LD_LIBRARY_PATH in a 'shell' rc file,
but then it effects ALL other compiles - NOT GOOD!
Note, the makefg script creates a run_fgfs.sh, thus it seems easier
to enter the fg folder, assumed /opt/bygg/fg in your case, and
use it...
/opt/bygg/fg$ ./run_fgfs.sh [OPTIONS]
...so I can compare different FG builds off each tree, excellent.
Or use ./run_fgrun.sh that is there also... or will be when you
get through the makefg script...
2. Running TG:
=
Terragear is a group of some 25 or so utilities, NOT a single
application, so it makes sense to have these 'executables'
available where ever you are building your scenery at the
time.
That is why they are all installed in a SINGLE location, and at
present the maketg script uses $HOME/bin. And that is why the
suggest .bashrc, or bash_aliases entry of :-
export PATH=${PATH}:$HOME/bin
is much more appropriate...
..ok, you use one or 2 etc different build trees for TG and FG
in your own $HOME ? And thenafter, you dump the binaries into
the _same_ $HOME/bin for the runtime fun?
..later, maybe make and install .deb's, .rpm's etc packages?
Do understand this?
..ok, maybe for my own fork then. ;o)
distcc ccache ccontrol dmucs
These seems off topic to maketg and makefg ;=))
..disagreed. ;o)
compile farm ... ok
recompiling only on the new source edits.
The auto make file system already does this!
..ok? This is where I would have picked ccache to do
the compile cache job.
Before that, there was compilecache, a bash script.
http://www.erikyyy.de/compilercache/
..offloading the work load so I can fly during compiles. ;o)
You can always 'fly' while compiling, and anyway if I really
want separation, I just start up different machines... ;=))
..is why I'd like to build throw-away .deb's. ;o)
I found a new bug with your maketg-1.0.3:
No, it is just that your '/bin/sh' did NOT expand the TAB (\t),
nor the new line (\n) characters...
These lines in your email show me that -
\nCFLAGS = -O -g
\trm -f $@
These scripts MUST be run in a shell that does expand tabs
and new lines. You will note at the top of the scripts
#!/bin/sh
#/bin/bash
Try reversing these, and try using 'bash'
#!/bin/bash
#/bin/sh
but NOT sure this will work...
Or configure or change your 'bin/sh' to one that DOES these
expansions... my system has :-
-rwxr-xr-x 1 root root 100856 2009-03-09 14:18 /bin/dash
version
Re: [Flightgear-devel] maketg and makefg scripts
Hi Arnt, Have just copied up version 1.0.5, which tries to get around the 'shell' question... Get these, and _DELETE_ all others... http://geoffair.net/tmp/maketg http://geoffair.net/tmp/makefg Version 1.0.5 Changes - 1 - version number and date, of course... 2 - package and tool update separated into several lines, since I found that sometimes using one LONG line of 'apt-get update a b c...' seemed to MISS some packages in the list!!! Not sure why? 3 - A work around for a standard shell (sh) that does not substitute echo \t to a TAB, 0x09, needed in the Makefile... 4 - a new switch, OSGNOUPD, to be used with DOUPD, that updates everything EXCEPT OSG, due to the time it takes for the OSG compile. The work around tries to 'test' if echo \t produces an 0x09, and if NOT, tries echo -e \t, and puts out noisy warnings if this second attempt fails also... and says you should do the Makefile MANUALLY ;=)) Other items - 1. more shell expansion/substitution I have experimented with #!/bin/bash, but find that it definitely does NOT expand \t unless written as echo -e \t, in my system. So the scripts have been left as #!/bin/sh, but I try to do a check if it is correctly substituting \t and if not, try using echo -e \trm etc, as mentioned. In my system /bin/sh is actually just a link to /bin/dash... so, effectively #!/bin/dash should be no different to #!/bin/sh 2. location of executables FG: Since I often have _MANY_ copies of this, with variations, changes, experiments, I do _NOT_ install this binary into any 'standard' location. So the scripts install this 'fgfs' exe into CURRENT WORK/install/fgfs/bin and run_fgfs.sh (and run_fgrun.sh) scripts are written in CURRENT WORK to run this executable, together with the pointer to OSG shared libraries it needs. The other components, including the important OSG shared libraries are thus installed into CURRENT WORK/install/component_name/lib, include and/or bin, so they can be 'used' in the script in a 'known' location... TG: Because this is a suite of tools that I want access to from whatever SCENERY WORK directory I am in at the time, then these are all installed to a SINGLE location. As a location for this I have chosen - $HOME/bin since I add this to my 'standard' PATH. 3. FG/TG trees In each CURRENT WORK I run BOTH makefg and maketg, since they share PLIB and OSG, and I use different directory names to separate cvs and git components... ..is why I'd like to build throw-away .deb's. ;o) Have never built a .deb, although I understand it is some form of packaging... I use a set of CURRENT WORK, like fg1, fg2, fg3, etc which I can run, trash or keep depending on my fancy ;=)) I am quite 'happy' with 'makes' update and dependence senses, thus no need for 'other' tools to help in this. The full compile time is just not that long, even if it does appear to sometimes needlessly re-compile certain things... And each component has a 'CLEAN' switch, like TGCLEAN, FGCLEAN, etc, to effectively start the full compile again... Anyway, hope these latest 1.0.5 work for you... Regards, Geoff. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] maketg and makefg scripts
On Wed, 18 Mar 2009 14:15:22 +0100, Arnt wrote in message
20090318141522.5c417...@a45.fmb.no:
On Tue, 17 Mar 2009 14:07:51 +0100, Geoff wrote in message
1237295271.6674.2.ca...@dell02:
Hi Arnt,
Without reviewing the maketg logs of the form templogNN.txt,
..doh! You still want my 1.0.2 logs?
No, but it will always help on some items, to be able
to 'see' the current log(s) if more errors. The 'log' you
included with your 3rd email, seems to be from using maketg
v 1.0.2??? The 'NN' number increments each time you use
maketg...
I have now put up versions 1.0.4 which -
(a) Outputs which version it is to the log, and date...
(b) Drops the lsb_release stuff, which I was NOT using anyway.
Get these, and _DELETE_ all others...
http://geoffair.net/tmp/maketg
http://geoffair.net/tmp/makefg
..thanks. :o)
Other matters...
And remember the script 'installs' the final TG executables
in $HOME/bin,
..sure? And not /opt/bygg/tg/install nor
/opt/bygg/tg/install/bin in my case???:
a...@a45:/opt/bygg/tg $ ll $HOME/bin
ls: cannot access /home/arnt/bin: No such file or directory
Yes, I AM SURE! The 'install' process CREATES directories
when they do not exist...
..funny, then I should be able to build in my /opt/bygg/*g/
trees and get the binaries into /home/arnt/bin, no?
Or, a dash bash bug? See below on your escape tests.
export PATH=${PATH}:$HOME/bin
You MUST change the script if you want them installed
elsewhere...
..ok, for my 2 (fg tg) trees, I will need
export PATH=${PATH}:/opt/bygg/fg/install/bin and
export PATH=${PATH}:/opt/bygg/tg/install/bin ?
Unh... NO!
1. Running FG:
=
If you 'really' wanted the 'fgfs' executable to be in
your path then you would need something like -
export PATH=${PATH}:/opt/bygg/fg/install/fgfs/bin
..actually, I prefer combine using the distro packaging system
(.deb in our case) and brlcad style naming to install and test
e.g. svn-fgfs-built-w-geoffs-maketg-with-bash-in-SG-from-git.
..but first, let's get your script working on my test box. ;o)
(32bit Debian Squeeze/Sid/unstable)
BUT this alone would NOT work, because 'fgfs' needs
access to the OSG shared libraries, which by the script, are
installed in /opt/bygg/fg/install/OpenSceneGraph/lib64
but there is a link created to it from -
/opt/bygg/fg/install/OpenSceneGraph/lib
So to be able to run fgfs from anywhere, which is the sole
reason for putting it in your PATH, then you would always need to
preceed it with -
~$ export LD_LIBRARY_PATH=/opt/bygg/fg/install/OpenSceneGraph/lib
~$ fgfs [OPTIONS]
or you could set up the LD_LIBRARY_PATH in a 'shell' rc file,
but then it effects ALL other compiles - NOT GOOD!
Note, the makefg script creates a run_fgfs.sh, thus it seems easier
to enter the fg folder, assumed /opt/bygg/fg in your case, and
use it...
/opt/bygg/fg$ ./run_fgfs.sh [OPTIONS]
...so I can compare different FG builds off each tree, excellent.
Or use ./run_fgrun.sh that is there also... or will be when you
get through the makefg script...
2. Running TG:
=
Terragear is a group of some 25 or so utilities, NOT a single
application, so it makes sense to have these 'executables'
available where ever you are building your scenery at the
time.
That is why they are all installed in a SINGLE location, and at
present the maketg script uses $HOME/bin. And that is why the
suggest .bashrc, or bash_aliases entry of :-
export PATH=${PATH}:$HOME/bin
is much more appropriate...
..ok, you use one or 2 etc different build trees for TG and FG
in your own $HOME ? And thenafter, you dump the binaries into
the _same_ $HOME/bin for the runtime fun?
..later, maybe make and install .deb's, .rpm's etc packages?
Do understand this?
..ok, maybe for my own fork then. ;o)
distcc ccache ccontrol dmucs
These seems off topic to maketg and makefg ;=))
..disagreed. ;o)
compile farm ... ok
recompiling only on the new source edits.
The auto make file system already does this!
..ok? This is where I would have picked ccache to do
the compile cache job.
Before that, there was compilecache, a bash script.
http://www.erikyyy.de/compilercache/
..offloading the work load so I can fly during compiles. ;o)
You can always 'fly' while compiling, and anyway if I really
want separation, I just start up different machines... ;=))
..is why I'd like to build throw-away .deb's. ;o)
I found a new bug with your maketg-1.0.3:
No, it is just that your '/bin/sh' did NOT expand the TAB (\t),
nor the new line (\n) characters...
These lines in your email show me that -
\nCFLAGS = -O -g
\trm -f $@
These scripts MUST be run in a shell that does expand tabs
and new lines. You will note at the top of the scripts
#!/bin/sh
#/bin/bash
Try reversing these, and try
Re: [Flightgear-devel] maketg and makefg scripts
On Wed, 18 Mar 2009 19:10:27 +0100, Geoff wrote in message 1237399827.6663.78.ca...@dell02: Hi Arnt, Have just copied up version 1.0.5, which tries to get around the 'shell' question... Get these, and _DELETE_ all others... http://geoffair.net/tmp/maketg http://geoffair.net/tmp/makefg ..got it, I'll first try a ./maketg NOPAUSE DOUPD to chk if it sees plib, your 1.0.4 and my 1.0.4a didn't. ;o) Version 1.0.5 Changes - 1 - version number and date, of course... 2 - package and tool update separated into several lines, since I found that sometimes using one LONG line of 'apt-get update a b c...' seemed to MISS some packages in the list!!! Not sure why? 3 - A work around for a standard shell (sh) that does not substitute echo \t to a TAB, 0x09, needed in the Makefile... 4 - a new switch, OSGNOUPD, to be used with DOUPD, that updates everything EXCEPT OSG, due to the time it takes for the OSG compile. The work around tries to 'test' if echo \t produces an 0x09, and if NOT, tries echo -e \t, and puts out noisy warnings if this second attempt fails also... and says you should do the Makefile MANUALLY ;=)) Other items - 1. more shell expansion/substitution I have experimented with #!/bin/bash, but find that it definitely does NOT expand \t unless written as echo -e \t, in my system. So the scripts have been left as #!/bin/sh, but I try to do a check if it is correctly substituting \t and if not, try using echo -e \trm etc, as mentioned. In my system /bin/sh is actually just a link to /bin/dash... so, effectively #!/bin/dash should be no different to #!/bin/sh 2. location of executables FG: Since I often have _MANY_ copies of this, with variations, changes, experiments, I do _NOT_ install this binary into any 'standard' location. So the scripts install this 'fgfs' exe into CURRENT WORK/install/fgfs/bin and run_fgfs.sh (and run_fgrun.sh) scripts are written in CURRENT WORK to run this executable, together with the pointer to OSG shared libraries it needs. The other components, including the important OSG shared libraries are thus installed into CURRENT WORK/install/component_name/lib, include and/or bin, so they can be 'used' in the script in a 'known' location... TG: Because this is a suite of tools that I want access to from whatever SCENERY WORK directory I am in at the time, then these are all installed to a SINGLE location. As a location for this I have chosen - $HOME/bin since I add this to my 'standard' PATH. 3. FG/TG trees In each CURRENT WORK I run BOTH makefg and maketg, since they share PLIB and OSG, and I use different directory names to separate cvs and git components... ..is why I'd like to build throw-away .deb's. ;o) Have never built a .deb, although I understand it is some form of packaging... I use a set of CURRENT WORK, like fg1, fg2, fg3, etc which I can run, trash or keep depending on my fancy ;=)) I am quite 'happy' with 'makes' update and dependence senses, thus no need for 'other' tools to help in this. The full compile time is just not that long, even if it does appear to sometimes needlessly re-compile certain things... And each component has a 'CLEAN' switch, like TGCLEAN, FGCLEAN, etc, to effectively start the full compile again... Anyway, hope these latest 1.0.5 work for you... Regards, Geoff. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] maketg and makefg scripts
Hi Arnt, ..I still need your TG-cs patch? yes, Yes, ABSOLUTELY YES!!! ... per mine of Monday, subject Re: [Flightgear-devel] .../maketg NOPAUSE DOUPD FG compile error: simgear/scene/bvh/BVHNode.hxx: No such file or directory ..ideas, STOPTOPATCH-TG after NOPAUSE, or a patches/ tree? Well it did STOP didn't it ;=)) And I added the patch to the bottom of the above reply... ..got it, I'll first try a ./maketg NOPAUSE DOUPD to chk if it sees plib, your 1.0.4 and my 1.0.4a didn't. ;o) IT WILL NOT 'SEE' PLIB UNLESS YOU PATCH configure.ac as detailed... And DOUPD is NOT required if this is a fresh directory ... you mentioned you are presently always starting new... Regards, Geoff. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] maketg and makefg scripts
On Wed, 18 Mar 2009 20:03:55 +0100, Geoff wrote in message 1237403035.6663.80.ca...@dell02: Hi Arnt, ..I still need your TG-cs patch? yes, Yes, ABSOLUTELY YES!!! ... per mine of Monday, subject Re: [Flightgear-devel] .../maketg NOPAUSE DOUPD FG compile error: simgear/scene/bvh/BVHNode.hxx: No such file or directory ..ideas, STOPTOPATCH-TG after NOPAUSE, or a patches/ tree? Well it did STOP didn't it ;=)) And I added the patch to the bottom of the above reply... ..got it, I'll first try a ./maketg NOPAUSE DOUPD to chk if it sees plib, your 1.0.4 and my 1.0.4a didn't. ;o) IT WILL NOT 'SEE' PLIB UNLESS YOU PATCH configure.ac as detailed... And DOUPD is NOT required if this is a fresh directory ... you mentioned you are presently always starting new... Regards, Geoff. ..ok, add a patches tree and PATCH-ALL and PATCH-* stanzas to your make*g-1.0.6's? ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] maketg and makefg scripts
On Wed, 18 Mar 2009 19:45:06 +0100, Arnt wrote in message 20090318194506.4214f...@a45.fmb.no: On Wed, 18 Mar 2009 19:10:27 +0100, Geoff wrote in message 1237399827.6663.78.ca...@dell02: Hi Arnt, Have just copied up version 1.0.5, which tries to get around the 'shell' question... Get these, and _DELETE_ all others... http://geoffair.net/tmp/maketg http://geoffair.net/tmp/makefg ..got it, I'll first try a ./maketg NOPAUSE DOUPD to chk if it sees plib, your 1.0.4 and my 1.0.4a didn't. ;o) Version 1.0.5 Changes - 1 - version number and date, of course... 2 - package and tool update separated into several lines, since I found that sometimes using one LONG line of 'apt-get update a b c...' seemed to MISS some packages in the list!!! Not sure why? ..could be related to whining about sudo apt-get install without (or before) chking whether those are necessary, try $basename --version style chks or dpkg -l |grep what ever your scripts needs. ..if everything needed is on board, there's no need to sudo. ..that said, there _is_ a use for build-time throw-away build tools, which could warrant KEEP-BUILD-TIME-TOOLS and THROW-AWAY-BUILD-TIME-TOOLS switches, e.g. tool and distro release etc debugging. ..running as root in $HOME or anything owned by $USER, should throw an error, in the Debian etc world, we do sudo aptitude install fakeroot ;man fakeroot . ;o) 3 - A work around for a standard shell (sh) that does not substitute echo \t to a TAB, 0x09, needed in the Makefile... 4 - a new switch, OSGNOUPD, to be used with DOUPD, that updates everything EXCEPT OSG, due to the time it takes for the OSG compile. ..sweet, I was thinking in terms of a STOP-TO-PATCH-TG switch or a patch tree. The work around tries to 'test' if echo \t produces an 0x09, and if NOT, tries echo -e \t, and puts out noisy warnings if this second attempt fails also... and says you should do the Makefile MANUALLY ;=)) ..Oh Horror!!!. ;o) Other items - 1. more shell expansion/substitution I have experimented with #!/bin/bash, but find that it definitely does NOT expand \t unless written as echo -e \t, in my system. So the scripts have been left as #!/bin/sh, but I try to do a check if it is correctly substituting \t and if not, try using echo -e \trm etc, as mentioned. In my system /bin/sh is actually just a link to /bin/dash... so, effectively #!/bin/dash should be no different to #!/bin/sh ..ln -s /bin/sh /bin/dash is standard Ubuntu practice? Debian uses Bash, and RH, SuSE, Mandrake etc I ever tried, all used Bash. 2. location of executables FG: Since I often have _MANY_ copies of this, with variations, changes, experiments, I do _NOT_ install this binary into any 'standard' location. So the scripts install this 'fgfs' exe into CURRENT WORK ..ok, why . and $COMPILE_BASE_DIR and $CDB, and not $PWD??? /install/fgfs/bin ..which in maketg-1.0.5 is ./install/$/bin or $COMPILE_BASE_DIR/$INSTDIR/bin and could be $PWD/$INSTDIR/bin etc. and run_fgfs.sh (and run_fgrun.sh) scripts are written in CURRENT WORK to run this executable, together with the pointer to OSG shared libraries it needs. The other components, including the important OSG shared libraries are thus installed into CURRENT WORK/install/component_name/lib, include and/or bin, so they can be 'used' in the script in a 'known' location... TG: Because this is a suite of tools that I want access to from whatever SCENERY WORK directory I am in at the time, then these are all installed to a SINGLE location. As a location for this I have chosen - $HOME/bin since I add this to my 'standard' PATH. ..ok, and will be in /opt/bygg/install/component_name/bin etc in my 1.0.5a. 3. FG/TG trees In each CURRENT WORK I run BOTH makefg and maketg, since they share PLIB and OSG, and I use different directory names to separate cvs and git components... ..ah, :o) I can mv -vf to merge my /opt/bygg/*g trees. ;o) ..is why I'd like to build throw-away .deb's. ;o) Have never built a .deb, although I understand it is some form of packaging... ..used in both Debian and its derivative Ubuntu, for your distro's FG .deb, you use sudo apt-get install fgfs etc. Oh wait! ;o) ..building things from source into .deb's, the Debian Way, also takes care of the dependencies. I use a set of CURRENT WORK, like fg1, fg2, fg3, etc which I can run, trash or keep depending on my fancy ;=)) ..aye, combining that idea with distro pack building and brlcad style binary naming, means we can do accidental releases on any cross-arch build that succeeds. ;o) I am quite 'happy' with 'makes' update and dependence senses, thus no need for 'other' tools to help in this. ..disagreed. ;o) The full compile time is just not that long, even if it does appear to sometimes needlessly re-compile certain things...
Re: [Flightgear-devel] maketg and makefg scripts
On Wed, 18 Mar 2009 22:31:57 +0100, Arnt wrote in message 20090318223157.15903...@a45.fmb.no: On Wed, 18 Mar 2009 19:45:06 +0100, Arnt wrote in message 20090318194506.4214f...@a45.fmb.no: On Wed, 18 Mar 2009 19:10:27 +0100, Geoff wrote in message 1237399827.6663.78.ca...@dell02: Hi Arnt, Have just copied up version 1.0.5, which tries to get around the 'shell' question... Get these, and _DELETE_ all others... http://geoffair.net/tmp/maketg http://geoffair.net/tmp/makefg ..got it, I'll first try a ./maketg NOPAUSE DOUPD to chk if it sees plib, your 1.0.4 and my 1.0.4a didn't. ;o) Version 1.0.5 Changes - 1 - version number and date, of course... 2 - package and tool update separated into several lines, since I found that sometimes using one LONG line of 'apt-get update a b c...' seemed to MISS some packages in the list!!! Not sure why? ..could be related to whining about sudo apt-get install without (or before) chking whether those are necessary, try $basename --version style chks or dpkg -l |grep what ever your scripts needs. ..if everything needed is on board, there's no need to sudo. ..that said, there _is_ a use for build-time throw-away build tools, which could warrant KEEP-BUILD-TIME-TOOLS and THROW-AWAY-BUILD-TIME-TOOLS switches, e.g. tool and distro release etc debugging. ..running as root in $HOME or anything owned by $USER, should throw an error, in the Debian etc world, we do sudo aptitude install fakeroot ;man fakeroot . ;o) 3 - A work around for a standard shell (sh) that does not substitute echo \t to a TAB, 0x09, needed in the Makefile... 4 - a new switch, OSGNOUPD, to be used with DOUPD, that updates everything EXCEPT OSG, due to the time it takes for the OSG compile. ..sweet, I was thinking in terms of a STOP-TO-PATCH-TG switch or a patch tree. The work around tries to 'test' if echo \t produces an 0x09, and if NOT, tries echo -e \t, and puts out noisy warnings if this second attempt fails also... and says you should do the Makefile MANUALLY ;=)) ..Oh Horror!!!. ;o) Other items - 1. more shell expansion/substitution I have experimented with #!/bin/bash, but find that it definitely does NOT expand \t unless written as echo -e \t, in my system. So the scripts have been left as #!/bin/sh, but I try to do a check if it is correctly substituting \t and if not, try using echo -e \trm etc, as mentioned. In my system /bin/sh is actually just a link to /bin/dash... so, effectively #!/bin/dash should be no different to #!/bin/sh ..ln -s /bin/sh /bin/dash is standard Ubuntu practice? Debian uses Bash, and RH, SuSE, Mandrake etc I ever tried, all used Bash. 2. location of executables FG: Since I often have _MANY_ copies of this, with variations, changes, experiments, I do _NOT_ install this binary into any 'standard' location. So the scripts install this 'fgfs' exe into CURRENT WORK ..ok, why . and $COMPILE_BASE_DIR and $CDB, and not $PWD??? /install/fgfs/bin ..which in maketg-1.0.5 is ./install/$/bin or $COMPILE_BASE_DIR/$INSTDIR/bin and could be $PWD/$INSTDIR/bin etc. and run_fgfs.sh (and run_fgrun.sh) scripts are written in CURRENT WORK to run this executable, together with the pointer to OSG shared libraries it needs. The other components, including the important OSG shared libraries are thus installed into CURRENT WORK/install/component_name/lib, include and/or bin, so they can be 'used' in the script in a 'known' location... TG: Because this is a suite of tools that I want access to from whatever SCENERY WORK directory I am in at the time, then these are all installed to a SINGLE location. As a location for this I have chosen - $HOME/bin since I add this to my 'standard' PATH. ..ok, and will be in /opt/bygg/install/component_name/bin etc in my 1.0.5a. 3. FG/TG trees In each CURRENT WORK I run BOTH makefg and maketg, since they share PLIB and OSG, and I use different directory names to separate cvs and git components... ..ah, :o) I can mv -vf to merge my /opt/bygg/*g trees. ;o) ..is why I'd like to build throw-away .deb's. ;o) Have never built a .deb, although I understand it is some form of packaging... ..used in both Debian and its derivative Ubuntu, for your distro's FG .deb, you use sudo apt-get install fgfs etc. Oh wait! ;o) ..building things from source into .deb's, the Debian Way, also takes care of the dependencies. I use a set of CURRENT WORK, like fg1, fg2, fg3, etc which I can run, trash or keep depending on my fancy ;=)) ..aye, combining that idea with distro pack building and brlcad style binary naming, means we can do accidental releases on any cross-arch build that succeeds. ;o) I am quite
Re: [Flightgear-devel] maketg and makefg scripts
On Thu, 19 Mar 2009 00:56:52 +0100, Arnt wrote in message 20090319005652.11c52...@a45.fmb.no: ..got it. ;o) ..into the wrong place, /opt/bygg/tg/install/terragear-cs/ and not /opt/bygg/tg/install/terragear-cs/bin/ etc. ;o) r...@a45:/opt/bygg/tg $ diff -U0 maketg-1.0.5 maketg-1.0.5a --- maketg-1.0.52009-03-18 19:19:15.0 +0100 +++ maketg-1.0.5a 2009-03-18 23:53:56.0 +0100 @@ -38 +38 @@ -SCVERSION=1.0.5 +SCVERSION=1.0.5a @@ -244,2 +244,5 @@ -TG_INSTALL_DIR=$HOME -INSTALL_DIR_TG=$HOME ..I pick one of these??? (TG_INSTALL_DIR and INSTALL_DIR_TG) +TG_INSTALL_DIR=$TG_SOURCE_DIR +# $INSTALL_DIR/$TG_INSTALL_DIR +# $HOME +INSTALL_DIR_TG=$INSTALL_DIR/$TG_INSTALL_DIR +# $HOME a...@a45:/opt/bygg/tg $ ll /opt/bygg/tg/install/terragear-cs/* total 26660 -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] maketg and makefg scripts
Hi Arnt,
Without reviewing the maketg logs of the form templogNN.txt,
..doh! You still want my 1.0.2 logs?
No, but it will always help on some items, to be able
to 'see' the current log(s) if more errors. The 'log' you
included with your 3rd email, seems to be from using maketg
v 1.0.2??? The 'NN' number increments each time you use
maketg...
I have now put up versions 1.0.4 which -
(a) Outputs which version it is to the log, and date...
(b) Drops the lsb_release stuff, which I was NOT using anyway.
Get these, and _DELETE_ all others...
http://geoffair.net/tmp/maketg
http://geoffair.net/tmp/makefg
Other matters...
And remember the script 'installs' the final TG executables
in $HOME/bin,
..sure? And not /opt/bygg/tg/install nor
/opt/bygg/tg/install/bin in my case???:
a...@a45:/opt/bygg/tg $ ll $HOME/bin
ls: cannot access /home/arnt/bin: No such file or directory
Yes, I AM SURE! The 'install' process CREATES directories
when they do not exist...
export PATH=${PATH}:$HOME/bin
You MUST change the script if you want them installed
elsewhere...
..ok, for my 2 (fg tg) trees, I will need
export PATH=${PATH}:/opt/bygg/fg/install/bin and
export PATH=${PATH}:/opt/bygg/tg/install/bin ?
Unh... NO!
1. Running FG:
=
If you 'really' wanted the 'fgfs' executable to be in
your path then you would need something like -
export PATH=${PATH}:/opt/bygg/fg/install/fgfs/bin
BUT this alone would NOT work, because 'fgfs' needs
access to the OSG shared libraries, which by the script, are
installed in /opt/bygg/fg/install/OpenSceneGraph/lib64
but there is a link created to it from -
/opt/bygg/fg/install/OpenSceneGraph/lib
So to be able to run fgfs from anywhere, which is the sole
reason for putting it in your PATH, then you would always need to
preceed it with -
~$ export LD_LIBRARY_PATH=/opt/bygg/fg/install/OpenSceneGraph/lib
~$ fgfs [OPTIONS]
or you could set up the LD_LIBRARY_PATH in a 'shell' rc file,
but then it effects ALL other compiles - NOT GOOD!
Note, the makefg script creates a run_fgfs.sh, thus it seems easier
to enter the fg folder, assumed /opt/bygg/fg in your case, and
use it...
/opt/bygg/fg$ ./run_fgfs.sh [OPTIONS]
Or use ./run_fgrun.sh that is there also... or will be when you
get through the makefg script...
2. Running TG:
=
Terragear is a group of some 25 or so utilities, NOT a single
application, so it makes sense to have these 'executables'
available where ever you are building your scenery at the
time.
That is why they are all installed in a SINGLE location, and at
present the maketg script uses $HOME/bin. And that is why the
suggest .bashrc, or bash_aliases entry of :-
export PATH=${PATH}:$HOME/bin
is much more appropriate...
..later, maybe make and install .deb's, .rpm's etc packages?
Do understand this?
distcc ccache ccontrol dmucs
These seems off topic to maketg and makefg ;=))
compile farm ... ok
recompiling only on the new source edits.
The auto make file system already does this!
..offloading the work load so I can fly during compiles. ;o)
You can always 'fly' while compiling, and anyway if I really
want separation, I just start up different machines... ;=))
I found a new bug with your maketg-1.0.3:
No, it is just that your '/bin/sh' did NOT expand the TAB (\t),
nor the new line (\n) characters...
These lines in your email show me that -
\nCFLAGS = -O -g
\trm -f $@
These scripts MUST be run in a shell that does expand tabs
and new lines. You will note at the top of the scripts
#!/bin/sh
#/bin/bash
Try reversing these, and try using 'bash'
#!/bin/bash
#/bin/sh
but NOT sure this will work...
Or configure or change your 'bin/sh' to one that DOES these
expansions... my system has :-
-rwxr-xr-x 1 root root 100856 2009-03-09 14:18 /bin/dash
version 0.5.4-8ubuntu1.1 - POSIX-compliant shell
As with _ALL_ scripts, there can be 'shell' incompatibilities,
but this nl/tab expansion should NOT be one of them!!!
Try running -
#!/bin/sh
# test-tab - test TAB expansion
MKFIL=/tmp/temptt.txt
echo # test tab expansion
echo \trm -f \$@ $MKFIL
echo # test new line expansion
echo \n\tar cr \$@ \$ $MKFIL
xxd $MKFIL
rm -f $MKFILE
echo Above should be -
echo 000: 0972 6d20 2d66 2024 400a 0a09 6172 2063 .rm -f \...@...ar
c
echo 010: 7220 2440 2024 3c0a r \$@ $.
Note first line of the dump begins with 09, not '\t', and has
two 0a...
If your shell does not do this, then GET ANOTHER ONE ;=))
And the automated 'gpc' stuff is not well suited to 'restarts'
so you should at least trash the gpc232 folder...
We seem to be getting close ;=)) remember, delete all previous
versions and only use 1.0.4, and maybe clean out the 'tmp'
log files now and again...
Since it is all SO automated, I often just 'trash', or rename
my current 'work' folder, and start again, and go
have coffee while it happens...
Regards,
Geoff.
--
Apps built with the
