[pkg-fgfs-crew] Scripted compilation of flightgear

Thu Mar 7 19:10:06 UTC 2013

Hi,

..apologies for the delay, perils of old junk failing when
you need it the most.  I was about to send this on Monday
when my main machine and then the backup box died. 
On Sun, 03 Mar 2013 22:13:08 +0100, Geoff wrote in message 
<1362345188.2422.5.camel at DELL02>:

> On Sun, 2013-03-03 at 06:54 -0500, Pat wrote:
> > So.. how many build script schemes are there?  
> 
> Hi Pat,
> 
> You pose some very interesting questions ;=)) Including 
> this first. I only know of mine and Brisa's, but 
> maybe there ARE others???
> 
> > Are you interested in discussing build scripts? If so, 
> > in what form or forum?
> 
> YES, but not being a 'forum' lover, nor IRC, to me, at 
> the moment, only by direct emails... or places where I 
> can get posts delivered automatically to me...
> 
> I certainly want questions, suggestion, problems to be 
> directly delivered to me, rather than me having to 
> regularly troll somewhere to find them...

..that makes us the majority. ;o)

> > Who else might be interested in discussing scripts?
> 
> Yes, who else?
> 
> > How are the flightgear build scripts different? 
> 
> Well my only answer is - mine is built by me, based on 
> Brisa's original download_and_compile (d&c)...
> 
> Thus contains my personal preferences and ideas...
> 
> > For each script
> >  Where can I get it?
> 
> Previously the latest was always at :-
>  http://geoffair.org/tmp/makefg
> That has stopped now...
> 
> Have now opened a repo to store it -
>  https://gitorious.org/fgtools/makefg
> And in this I bumped the version to 1.3.14
> 
> This is because I have no commit rights on the 'official' 
> FG repo, where d&c is stored ;=\...
> 
> > Who uses it? What's the audience?
> 
> No idea ;=))

..how many downloads?

> > Why would someone use it and not another
> 
> Again, no idea ;=))
> 
> > How many people use it
> 
> Yet again, no idea ;=))
> 
> > Who's in charge of it
> 
> Well ME, but now that it is a gitorious repo, would 
> WELCOME other collaborators. Just send me your gitorious 
> 'username' and I will give you at least commit rights...
> 
> > Is it regularly maintained
> 
> Hmmmm, yes, and no. At the moment only when I find, 
> or someone points out a specific problem...
> 
> But as mentioned below, I REGULARLY use it to build 
> the latest 'next' SG/FG at least...
> 
> > Who maintains it
> > Who helps maintain it
> 
> See above...
> 
> > What environments does it work in
> 
> I ONLY have the above Ubuntu 12.04 LTS 64-bit environment 
> for testing, so have no answer to this...

..makefg works for me if I drop openrti, openrti and SG
builds ok with D&C but my all FG build_s_ fails. 

> > What does it do well
> 
> Not for me to say ;=)) I like it, and I use it...
> 
> > What's missing and desired in it
> 
> I do NOT regularly test it to build FGRUN, 
> ATLAS, and TerraGear (TG), but it should do ALL 
> of these, and more...
> 
> To that list I would ADD - FGCOM, FGCOMGUI, FGX, 
> FGMS, CROSSFEED, OPENRADAR, to name a few... 
> 
> In fact ANYTHING related to FG!
> 
> And it should ALWAYS create a run-????.sh, to 
> really assist in the first time such a component 
> is run...
> 
> > What does the maintainer NOT want in it
> 
> Hmmm, that is a difficult question to answer! In 
> simple terms, nothing is presently particularly
> banned ;=)). And every direction is welcome...
> 
> One thing is at present my script STOPS on a build  
> error. I would want to maintain this.

..and in a tree script world, throw a mail to the job 
owner and keep the other builds going and logged.

> The last time I looked, the d&c script v1.4 uses 
> tee to output to the log, and thus will not particularly 
> stop on some build error, since the last 'make' action 
> is tee, which succeeds... a quite BIG compromise on what 
> is written to the build log...
> 
> And another deliberate intention is to NOT install 
> into the standard 'system' paths... It mostly only 
> installs 'locally', so MULTIPLE FG versions can be 
> kept...

..another approach is build distro packages, and then use 
the packaging system to keep track of the installs, is why 
I want the distro packagers input, most distros would script 
their flightgear packaging.

> But maybe further insights to my thoughts on its 
> direction are given below as I answer Arnt's 
> email...
> 
> And I had to look up 'stochastically' ;=)) But 
> thanks for this new word...
> 
> Hi Arnt, 
> 
> Re: makefg 1.3.13, now 1.3.14
> 
> Sorry, not sure I know what you are really trying 
> to do! 

..inspire.  Looks like it works ;o), I've got 1.3.15.

..but on the horizon I see everybody running all kindsa 
weird stuff on top of Xen etc virtual machines, allows
setting up all Wintendo versions and a bunch of distros
side by side, and run them side by side, to e.g. compare 
a new tweak's performance without having to reboot, the 
OS'es can be set up in e.g. throw-away installs that runs 
_once_ to see how they die etc on bad FG bugs.

..my symlink lost a coupla vocals and mkfg runs ok, 
except I get a wee name clash, makefg needs to live 
_outside_ my FG-git tree now:
mkfg: Done all FG. in dir /home/arnt/FG-git/flightgear/build
mkfg: FGRUN skipped.
mkfg: ATLAS skipped.
mkfg: Created run_fgfs.sh
mkfg: Created run_fgviewer.sh
mkfg: To view a model, run the ./run_fgviewer.sh, followed by a model
(.ac) file name
mkfg: To start fgfs, run the ./run_fgfs.sh file
mkfg: FG data skipped.
mkfg: Done [ SG FG], and the output log is
[/home/arnt/FG-git/tmp/templog24.txt]
mkfg: Items skipped = [ TOOLUPD PLIB OSG FGRUN ATLAS FGDATA]
mkfg: Updating file mkfg/mkfg-1.3.15.conf...
mkfg: line 1448: mkfg/mkfg-1.3.15.conf: Not a directory
arnt at celsius:~/FG-git$ 

> I have not been following this thread that well ;=(( 
> And obviously I do not use download_and_compile since 
> I have my own script...

..I tried both, on and off, nowadays, 
they do different parts of the job.

> But as far as my 'makefg' script is concerned, 
> and concerning a NEW build in another blank 
> directory, it will check for a file -
>  $HOME/bin/<script-name>-<script-version>.conf
> and if found will use the fgdata directory 
> given in there...
> 
> That 'config' file is ONLY written if the script 
> is run to the end. It is nearly the last instruction.
> And can be messed up by renaming the script like I 
> have seen you do makefg -> makefg-1.3.13, etc...

..IMO you should write it first, and call it makefg.tmp-conf 
or somesuch, then build and mv it makefg.conf if it builds 
ok, and e.g. makefg.bad-conf when it fails.

..or a better way, have one script build the config file, 
and the other build the programs specified in the config 
file.  

> I did not know there was a gitorious terms of service
> (500MB/month), but I certainly did NOT want to 
> clone that enormous pure data block again and AGAIN, 
> just due to the time it takes, and the disk space 
> consumed...
> 
> That would include a clone of a local clone, which I 
> have NEVER tried...

..this last time I tried the git bundle way instead 
of the tarball way.

> And even if the script does not find that config 
> file, you can tell it where 'fgdata' is, like -
>   FGDATADIR=<path>
> When it finds that path, it will read the 'version' 
> file, and display to you what version it found.
> 
> And it should be remembered the only real use 
> of that directory is to write the run-fgfs.sh 
> script correctly...
> 
> Similar with OSG. If you give it some other 
> OSG install directory - OSGPATH=<full-path> - the 
> script will use that... 

..aye.  Now try "osgversion ;which osgversion \
;osgversion --help ;osgversion --version-number "
for automation ideas. :o)

> And for PLIB, BOOST, etc...
> 
> And another important first time run in a new 
> directory is the command NO_TOOL_UPD, since I know 
> some of this is 'broken' for the multiple possible 
> unix/linux repos it could be run in... read various 
> versions of the 'tools/packages'...
> 
> Also my script does NOT get involved in git 
> branches, or tags. I tried some of that but it 
> just got far, FAR TOO messy... ;=((

.. :oD

> But you could manually checkout a new branch in 
> SG/FG/FGDATA and use the script to build in a 
> new build directory for each branch...
> 
> I presently do that having a 'next' and a 'release' 
> builds. but as indicated it needs some manual 
> steps...
> 
> As you point out, I do not think a single script 
> should try to do EVERYTHING possible ;=)) It can not 
> make coffee the way you may like it...
> 
> As to no problem with RTI, my script has this 
> OFF by default, as it is in the FG CMakeLists.txt 
> file. 
> 
> I have never tried a build enabling it - that is 
> add FG_ENABLE_RTI to the scripts command, so do 
> not personally know it there is a problem with 
> RTI or not...

..I've tried it, makefg fails here.  

> HTH.
> 
> Regards,
> Geoff.
> 
> REPO: https://gitorious.org/fgtools/makefg
> 
> 
> 
> 

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...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.