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 0.5.4-8ubuntu1.1 - POSIX-compliant shell ..I have: a...@a45:/opt/bygg/tg $ ll /bin/sh lrwxrwxrwx 1 root root 4 Mar 2 01:22 /bin/sh -> bash a...@a45:/opt/bygg/tg $ /bin/sh --help GNU bash, version 3.2.48(1)-release-(i486-pc-linux-gnu) Usage: /bin/sh [GNU long option] [option] ... /bin/sh [GNU long option] [option] script-file ... > As with _ALL_ scripts, there can be 'shell' incompatibilities, > but this nl/tab expansion should NOT be one of them!!! ..appears it is: a...@a45:/opt/bygg/tg $ ./geoffstest ;./geoffstest-bash \ ;./geoffstest-dash # test tab expansion # test new line expansion 0000000: 5c74 726d 202d 6620 2440 0a5c 6e5c 7461 \trm -f $...@.\n\ta 0000010: 7220 6372 2024 4020 243c 0a r cr $@ $<. Above should be - 0000000: 0972 6d20 2d66 2024 400a 0a09 6172 2063 .rm -f [email protected] 0000010: 7220 2440 2024 3c0a r $@ $<. # test tab expansion # test new line expansion 0000000: 5c74 726d 202d 6620 2440 0a5c 6e5c 7461 \trm -f $...@.\n\ta 0000010: 7220 6372 2024 4020 243c 0a r cr $@ $<. Above should be - 0000000: 0972 6d20 2d66 2024 400a 0a09 6172 2063 .rm -f [email protected] 0000010: 7220 2440 2024 3c0a r $@ $<. # test tab expansion # test new line expansion 0000000: 0972 6d20 2d66 2024 400a 0a09 6172 2063 .rm -f [email protected] c 0000010: 7220 2440 2024 3c0a r $@ $<. Above should be - 0000000: 0972 6d20 2d66 2024 400a 0a09 6172 2063 .rm -f [email protected] 0000010: 7220 2440 2024 3c0a r $@ $<. a...@a45:/opt/bygg/tg $ > Try running - > #!/bin/sh ..#!/bin/dash does do your thing. >From "man dash": DESCRIPTION dash is the standard command interpreter for the system. The current version of dash is in the process of being changed to conform with the POSIX 1003.2 and 1003.2a specifications for the shell. > #< 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 "0000000: 0972 6d20 2d66 2024 400a 0a09 6172 2063 .rm -f > \[email protected] c" > echo "0000010: 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 ;=)) ..um, Debian Policy... ;o) ... have dash onboard for tests. Maybe use #!/bin/dash instead of #!/bin/sh in your script, first test now in progress. > And the automated 'gpc' stuff is not well suited to 'restarts' > so you should at least trash the gpc232 folder... ..aye, is why I start with full wipes for now. ;o) > 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... ..I just mv -vf tmp tmpo/tmp-`date +%F+%T` ;o) > 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... -- ..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 [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
