Re: [Flightgear-devel] download_and_compile.sh - version 1.9.12 finally ready

[Pat]

Geoff,

Thanks for testing this.  

I left a set -x on line 371 which causes the double output you're
seeing on -h. I've removed it.
 
Also, I've changes the svn
for plib to http://svn.code.sf.net/p/plib/code/trunk/.

OSG and PLIB are slated for different treatment in a future version.

If the chosen version of OSG, or the 1.8.5 version of PLIB is
installed or previously built, there's no reason to reconfigure
or rebuild them.

In general, I'd like to be able to detect when git does not add a file
to the sources.  Then I could condition the configure step on whether
its actually needed or not.  If I find a way to do that quickly, it
could be applied to any component that uses git, not just OSG.

I'll be using your approach for plib at least.

The latest is still 1.9.12:

https://www.gitorious.org/fg/fg-download-and-compile-fgmeta/raw/master:download_and_compile.sh

-Pat

On Thu,
10 Oct 2013 12:50:15 +0200 Geoff McLane  wrote:

> Hi Pat,
> 
> Finally got a chance to try download_and_compile.sh 
> 1.9.12 from the ...-fgmeta repo...
> 
> I think you need to adjust the svn repo for plib! It 
> has permanently changed I think
> 
> About ln 649
>   svn $PLIB_STABLE_REVISION_ co
> http://plib.svn.sourceforge.net/svnroot/plib/trunk/ plib 
> to the new repo
>   svn $PLIB_STABLE_REVISION_ co
> http://svn.code.sf.net/p/plib/code/trunk plib 
> 
> Also, as a suggestion, why not first search the system for an 
> installed plib, and use that rather than a new download 
> and compile? These days I have add plib as a 'system'
> install...
> 
> In my makefg, which as you know was based on one of 
> Brisa's original versions, circa Jan 2009, I use 
> script like -
> 
> # if NO plib installed path from user, and none from
> # previous configuration file, then
> if [ -z "$INSTALL_DIR_PLIB" ]; then
> # try the 'system' places
> PLIB_PATH="/usr"
> if [ -f "$PLIB_PATH/include/plib/ul.h" ]; then
> show_plib_version $PLIB_PATH
> PLIB_INSTALL_OK=1
> elif [ -f "$PLIB_PATH/local/include/plib/ul.h" ]; then
> show_plib_version "$PLIB_PATH/local"
> PLIB_INSTALL_OK=1
> else
> PLIB_PATH=""
> fi
> fi
> 
> The function 'show_plib_version' just reads the version
> from the ul.h header...
> 
> Anyway, just a suggestion...
> 
> After the above svn correction, the script ran to 
> the end, building fgcom, fgfs, fgrun, openrti,
> OpenSceneGraph, plib, simgear... great stuff...
> 
> I only had a chance to try it with the ALL option ;=))
> 
> But found out later that is not really 'ALL'. I could 
> add FGX, FGO?, FGCOMGUI, ATLAS and DATA, but I have 
> already done the DATA separately overnight... 
> 
> I will try to get around to trying the others... 
> presently doing -p FGX, but it insists on rebuilding 
> OSG which is slow...
> 
> One little thing. When I say run it with the -h help 
> option for example my bash shell echos the echo 
> lines, like the script has say -
>echo "Switches:"
> 


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] download_and_compile.sh - version 1.9.12 finally ready

[Pat]

Version 1.9.12 will build 

2.10.0 as stable with -s, 
next without the -s 
2.12.0 with -B release/2.12.0
master with -B master

can someone do a final check on
https://www.gitorious.org/fg/fg-download-and-compile-fgmeta/raw/6516d8db2c0ab3cf19722b5d3aa49e2860b6cf9b:download_and_compile.sh

i've built each of the above and run the resulting flightgear 
I'd like to
have someone besides me test it before we go ahead with the merge to the
main fgmeta archive.

Also, there's another version coming right after this that builds
2.12.0 as stable 

-Pat

Here's the complete release notes:

Version 1.9.12 release version of 1.9.12
function write_log() added.
write_log writes summary information to sysout and a summary
log file the function is added as a preview of changes to the logging
for the script function SET_WINDOW_TITLE()
changes the window title to indicate what is being built.
function check_build()
writes to the summary log a list of what was found as
executables after a build. outputs a rebuild command
the rebuild command can be used to re-execute the same build
without entry of options or parameters.

removes fgcomgui from the list of modules built when ALL is specified

STOP_AFTER_ONE_MODULE
Adds options z, B, R and G

option z will set this so that only one module will be built, and then
the script will immediately stop.  This is useful during testing of the
script.

Option B allows the build of a specific branch. Without the R option it
will build the head of the branch. option R allows the build of a
specific revision or commit. Option G allows selection of a specific
version of OpenSceneGraph.

This version introduces the use of a bash associative array to select
branch and version for building.

patches allow building with fltk under Ubuntu 13.04

Open radar has been added


--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Scripted Installation - An update and a summary of where things stand.

[Pat]

I'm going to try to limit the versions to one focused change set from
now on.  That may make the changes smaller and easier to understand
and test.

updated team master 1.9.12 (bugfix and preliminary logging changes
useful for debugging 1.9.12) 

team next now contains a version 1.9.13 (main logging changes)

Version 1.9.13 address the -x and -v log output not appearing in the log
file

Version 1.9.14 will address directory management. (fgsrc, othersrc and
using directory variable names instead of cd .. and cd - )

-Pat

download_and_compile.sh 1.9.13-pre1

1. download_and_compile.sh log file's name is changed to
   download_and_compile.log

2. Previously the log file contained only data specifically
   directed to $LOGFILE.  1.9.13 directs all output to
   download_and_compile.log.  Visually distracting constructs
   like  2>&1 | tee -a $LOGFILE are no longer found throughout
   the script.
3. When -x and/or -v is used, the output of -x and -v is
   visible in the log file.

4. download_and_compile_summary.log, added in 1.9.12,
   now contains a list of the start and finish times
   for each build step

5. Miscellaneous historical comments have been removed

6. write_log(), introduced in 1.9.12 is used more.
   write_log puts output in download_and_compile.log and
   in download_and_compile_summary.log

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Anyone need an aircraft project?

[Pat]

http://www.stumbleupon.com/su/4thYJO

Oh.  And when you're done, that laptop in the back should click open and
display the flightgear splash screen.

-Pat

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Scripted Installation - An update and a summary of where things stand.

[Pat]

Lets review where things stand with the script:



Current commit on team clone:
 download_and_compile.shAug 31 2013 #58ae270 Version
 1.9.12 (Pat)

http://www.gitorious.org/fg/fg-download-and-compile-fgmeta/raw/58ae27079531e69ec48c6df06538559680bd9433:download_and_compile.sh

Contains a fix to a bug found and reported by Arnt.

Additional testing is needed before this can be merged to the main
fgmeta.

A detailed list of the changes in the script version
1.9.12 can be found here:

http://www.gitorious.org/fg/fg-download-and-compile-fgmeta/commit/58ae27079531e69ec48c6df06538559680bd9433
Francesco approved an early version of 1.9.12. There have been
additional small changes made.  

-Pat




For Arnt and others interested in where things are going, the following
summarizes a lot of stuff that's already been said here and elsewhere.

The current "official" script in fgmeta is 1.9.11 
It builds 2.8.0 as stable and will build next. It would need small
modifications to build 1.9.10 or 1.9.12 

Arnt has requested details on any new design for the directory
structure.  I've given one below, but I'm open to suggestions if you'd
prefer something different.

Here are the design goals:

1.  download_and_compile.sh continues to work exactly as it has in the
past.  It will continue to use the same directory structure unless
the user decides to take an action that causes a new directory
structure to be adopted for subsequent builds.

2.  Minimize the impact on git and svn servers by removing the need to
download multiple copies of sources and data.

3.  Facilitate testing the script with different versions and options.

To meet these goals there are several features being added to the
script.  Some of these are partially in place, some will require
additional changes.

Changes through script version 1.9.12:
=== === == === ===

1. Terminal Window Titles

2. Additional versions of OSG supported

3. Support for any branch, including the soon to be released flightgear
   2.12.0.  2.10.0 is considered stable at this point in time.

4. Use manually placed fgdata copies in the parent of the build
   directory.  

   Copies of fgdata git repositories can be placed in directories
   named fgdata_2.8.0, fgdata_2.10.0, fgdata_2.12.0 and fgdata_2.99.9. 
   
   If download_and_compile.sh is run from a sub-directory of the 
   directory containing the fgdata* directories, instead of downloading 
   a separate copy of fgdata, the script will simply create s symbolic
   link to the correct fgdata git copy.  

   Note that initially all the copies' versions do not have to match
   the directory name.  Any recent version of fgdata will do.  When it
   runs, the script will update the version you are building to be the
   correct version of fgdata.

   This approach to keeping multiple fgdata versions 
   means you never have to download fgdata more than once.  

1. You can blow away a build and not have to redownload fgdata
2. You can have multiple variant builds of a single version all
   using the same fgdata_*/fgdata version
3. You can build different versions of flightgear and still not
   have to download another fgdata

== 
Future Changes:
== 


1. Change the directory structure for sources to allow a single copy of
   the sources to be used for multiple versions and variants without
   having to download the sources repeatedly.

   Similarly to the placement of the fgdata_* copies, create new
   directories for sources: 

fgsrc
which will contain sources for anything native to
flightgear
othersrc 
which will contain sources for plib and as many
versions of OSG as you need.

Builds will be done in a subdirectory, one per variant

It will look something like:

download_and_compile.sh

fgdata_2.10.0
fgdata
fgdata 2.12.0
fgdata
fgdata 2.99.9
fgdata
fgsrc
flightgear
simgear
openrti
fgcom (unless we abandon the separate fgcom)
fgrun
etc.
othersrc
OpenSceneGraph-3.0.1
OpenSceneGraph-3.1.9

plib-1.8.5

variant-2.12.0-openrti
build
install
compilation_log.txt

variant-2.10.0-noopenrti
build
install
compilation_log.txt

variant-master-openrti
variant-master-noopenrti
variant-next-noopenrti
variant-next-noopenrti
and so forth.


Note that with 1.9.12 and later its possible to build the
master branch.

Usage:

cd variant-master-openrti
../download_and_compile.sh [option

Re: [Flightgear-devel] Scripted installation

[Pat]

I've just updated the script to version 1.9.12 with various changes.

http://www.gitorious.org/fg/fg-download-and-compile-fgmeta/raw/8b99f5eb7be14708c156424af661cb88c68ecb30:download_and_compile.sh

see
http://www.gitorious.org/fg/fg-download-and-compile-fgmeta/commit/8b99f5eb7be14708c156424af661cb88c68ecb30
 
for details.

I've requested that this version be merged to the main fgmeta
repository on master and next.

The main point of the update is that this version builds 2.10.0 as
stable (-s option) , 2.12.0 and master using the new -B option and
next, as usual with no option


 -Pat



On Wed, 28 Aug 2013 16:22:07 +0200
Gijs de Rooy  wrote:

> > Wil wrote:
> > Is the link you gave the master or next branch?
> 
> That was the master branch. For other branches, it's easiest to go to
> www.gitorious.org/fg/fgmeta/source/download_and_compile.sh and select
> your preferred branch from the dropdown on the right. It's next to
> the "Raw blob" link that you can use to download the file.
> 
> Gijs
> 

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Scripted installation

[Pat]

On Fri, 23 Aug 2013 21:28:28 -0400
Pat  wrote:

> On Fri, 23 Aug 2013 17:14:34 -0400
> Thanks,
We can change this in a future version unless you are still having
trouble...

I get no error now, just a redirect:
svn -r 2172 co  http://svn.code.sf.net/p/plib/code/trunk
Utrunk/src/ssg/ssg.h
Checked out revision 2172.

-Pat

By the way, I noticed there is a 2173 revision, but it changes only ssg
which we do not use.

> 
> We'll include this in thu about to be released script version 1.9.12
> 
> -Pat Callahan
> 
> Wil
> Neeley  wrote:
> 
> > I fixed it by  editing line 449 to
> > svn $PLIB_STABLE_REVISION_ co
> > https://svn.code.sf.net/p/plib/code/trunkplib
> > 
> > Wil Neeley
> > 
> > 
> > On Fri, Aug 23, 2013 at 5:12 PM, Wil Neeley 
> > wrote:
> > 
> > > When running the scripted installation on Crunchbang I get the
> > > following error.
> > > svn: Repository moved permanently to '
> > > http://svn.code.sf.net/p/plib/code/trunk'; please relocate
> > > How can I fix it
> > >
> > > Wil Neeley
> > >
> 


--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Scripted installation

[Pat]

On Fri, 23 Aug 2013 17:14:34 -0400
Thanks,

We'll include this in thu about to be released script version 1.9.12

-Pat Callahan

Wil
Neeley  wrote:

> I fixed it by  editing line 449 to
> svn $PLIB_STABLE_REVISION_ co
> https://svn.code.sf.net/p/plib/code/trunkplib
> 
> Wil Neeley
> 
> 
> On Fri, Aug 23, 2013 at 5:12 PM, Wil Neeley 
> wrote:
> 
> > When running the scripted installation on Crunchbang I get the
> > following error.
> > svn: Repository moved permanently to '
> > http://svn.code.sf.net/p/plib/code/trunk'; please relocate
> > How can I fix it
> >
> > Wil Neeley
> >


--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FGCOM

[Pat]

For those of us with certain kinds of hearing disabilities, adding any
distortion or reduction in volume might make communication impossible.
Our ears add an incredible amount of distortion and noise already. On
top of that you wouldn't believe the lousy quality of hearing aid sound
at 133Db.

There has to be an option in flightgear to allow clear communication,
even at a distance.

That said, I'd never make it in a real cockpit.  Current real aircraft
 audio is just about impossible to understand.


 On Sat, 17 Aug 2013 13:07:25 + TDO Brandano
 wrote:

> I'd leave to the client the task of distorting the received signal
> based on the distance and other environmental parameters. The server
> should just re-broadcast the clear signal, maybe culling over a
> simple range bubble.
> 
> 
> From: clem...@hotmail.fr
> To: flightgear-devel@lists.sourceforge.net
> Date: Sat, 17 Aug 2013 03:02:37 +0200
> Subject: Re: [Flightgear-devel] FGCOM
> 
> 
> 
> 
> Hi Holger,
> 
> I'm glad to know that FGCom integration is surprising you.
> It seems you have a pretty well vision of the perfect solution for
> radio simulation and I agree with you on this "how-it-should-works".
> As James said, all of this is mostly based on P2P architecture which
> is far to be the easier things to create :)
> - Each client need to know the position of others clients
> - Each client must send a _clean_ sound signal (no distortion, no
> attenuation...)
> - Each client need to calculate the distorsion/attenuation of others
> clients depending of their distance (I'm callsign01; callsign02 is at
> 20nm from me = I can hear him loud, callsign03 is at 120nm from me =
> I can hear him quiet, callsign04... etc... etc...)
> 
> We could also use a centralized architecture with a server which
> could works like:
> - I know the position and frequency of each clients
> - callsign01 is speaking on 122.50MHz
> - callsign02 is listening on 122.50MHz, the distance between
> callsign01 and callsign02 is 20nm = I send a clean signal from
> callsign01 to callsign02
> - callsign03 is listening on 122.50MHz, the distance between
> callsign01 and callsign03 is 120nm = I send a distorted/attenuated
> signal from callsign01 to callsign02
> - ...
> - ...
> 
> I can't imagine the amount of work to create this new system. Also I
> have absolutely no idea where we should start if we really want
> (need?) this _much_ realistic system. Do you have any hint ?
> 
> For sure this level of realism would be a really nice feature. But I
> admit I don't know if our users will be _much_more_ happy with this
> level of realism and they need/want this level of realism OR are they
> already very happy to have a "simple" way of communication better
> than a simple TeamSpeak-like application ? In this case is it
> necessary to work during months and months on this project ? Is it
> worth ?
> 
> Of course if this level of realism I would be happy to use it ! But
> I'm not sure to be ready to work on this (big) project for only few
> of our "pro-realistic" users. But if the task is supported by some
> people, devs are involved, and my skills are sufficient, yes I would
> be part of this effort ;)
> 
> 
> Regards,
> Clément 
> 
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with 
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
> 

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] 2.12 is branched

[Pat]

> 
> If we are going to slip the release, we should only do so once :)
> 
> -Stuart
> 

One reschedule is a good idea.  Would an indefinite delay, with a
promise republishing the schedule by a given date be appropriate or
desirable?

For example

"Due to constraints on our developers' available time, we are
rescheduling the release of the next version of our highly successful
"All in One Integrated Development Environment and Espresso Machine*" 

We expect to have a revised schedule by the second Tuesday of next week"


-Pat

*We're not sure about your code, but your coffee will be worthy of
poetry!

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] fgdata space in filenames

[Pat]

I would think a maintainer would not object to a file name change of
this type.

-Pat

On Sat, 10 Aug 2013 16:13:04 +0200 jean pellotier
 wrote:

> i finally did a merge request with the correction to the offending 
> files, tell me if this a thing to do, or i should wait for the 
> maintainers to react (but some are not actif anymore).
> 
> https://gitorious.org/fg/fgdata/merge_requests/114
> 
> jano
> 
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead. 
> Download for free and get started troubleshooting in minutes. 
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel


--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Building Older versions of flightgear on updated operating systems

[Pat]

If there is something that we could fix that prevents previous versions
of flightgear or an ancillary package such as fgrun from building
correctly, should we fix it in the git branches for our releases?

At this point neither Flightgear or fgrun versions 2.10.1, 2.10.0 or
2.8.0 build for me on Ubuntu 13.04.  Changes to 2 CmakeLists.txt
files are already made and work on 13.04 in 2.12.0.

If I ask for a merge of the two corrected CMakeLists.txt files in
Flightgear and FGRUN 2.10.1, 2.10.0 and 2.8.0, how will this be
received. Would these patches be accepted and merged to the 2.10.0 and
2.8.0 branches? Would the tag for 2.10.0 and 2.8.0 be updated?

I won't do any work on this unless its agreed in advance that the
patches should be merged and what tags should or should not be updated.

Does anyone care about 2.10 at this point?
What are your thoughts on updates to previous versions to keep them
viable?

 -Pat

Background.

 In recent months, after upgrading to Ubuntu
13.04, I was seeing errors like the one below when building flightgear
or fgrun on the 13.04 installation. Building on Ubuntu 12.10 continues
to work correctly. The problem is fixed in Flightgear branches next
master and 2.12.0

There are two small patches to CMakeLists.txt that address this. one for
flightgear, the other for fgrun. While next, master and 2.12.0 have
them, earlier branches do not. Without these patches, flightgear and
fgrun  will not compile on Ubuntu 13.04.

Causes:

There are reports from several open source projects attempting to build
against fltk on various distributions, having the exact same issue.

>From what I've read, the problem may lie in one of several possible
areas:

o changes in the way libraries are structured by distributions. 

These changes seem to require libdl to be explicitly included at some
level in applications that use fltk such as Flightgear. Previous
version of the distribution did not have this issue.

o Static linking vs dynamic linking

There's a note regarding this on the FLTK mailing lists

o Cmake's find_FLTK

Shouldn't this include libdl when necessary? 
Has this been done for any version of fltk?
Has this been done in any version of CMake.

I'll inquire on the fltk mailing list.

 -Pat


[ 99%] Built target FGAdminUI
Linking CXX executable fgadmin
/usr/bin/ld: /usr/lib/i386-linux-gnu/libfltk.a(Fl_Preferences.o):
undefined reference to symbol 'dlopen@@GLIBC_2.1' /usr/bin/ld: note:
'dlopen@@GLIBC_2.1' is defined in DSO /lib/i386-linux-gnu/libdl.so.2 so
try adding it to the linker command
line /lib/i386-linux-gnu/libdl.so.2: could not read symbols: Invalid
operation collect2: error: ld returned 1 exit status make[2]: ***
[utils/fgadmin/src/fgadmin] Error 1 make[1]: ***
[utils/fgadmin/src/CMakeFiles/fgadmin.dir/all] Error 2 make: *** [all]
Error 2

--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] 2.12 is branched

[Pat]

Would some sort of user data directory help with this?
Can this be done on ubuntu?

On Thu, 1 Aug 2013 21:16:50 -0500
Saikrishna Arcot  wrote:

> For what it's worth, I have a
> PPAthat
> is tracking the 2.12.0 branch that includes the default aircraft and a
> few other aircraft that can be used by Ubuntu and other distros that
> use/allow Ubuntu's repos and/or PPAs. However, it installs these
> files to /usr/games and /usr/share/games, which some people frown
> upon because it doesn't allow easy changes.
> 
> 
> Saikrishna Arcot
> 
> 
> On Wed, Jul 31, 2013 at 11:40 AM, Gijs de Rooy 
> wrote:
> 
> > Hi all,
> >
> > is there any news on release candidates? I think we did find a few
> > serious bugs last
> > year when people tried the RCs, so we'd better start distributing
> > them before the
> > end of this week...
> >
> > Cheers,
> > Gijs
> >
> >
> > --
> > Get your SQL database under version control now!
> > Version control is standard for application code, but databases
> > havent caught up. So what steps can you take to put your SQL
> > databases under version control? Why should you start doing it?
> > Read more to find out.
> > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> > ___ Flightgear-devel
> > mailing list Flightgear-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/flightgear-devel
> >
> >


--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] The latest on Download_and_compile.sh

[Pat]

The download_and_compile team clone has been rebuilt as of 1:15 AM
Tuesday, July 30, 2013 (UTC) if you cloned it locally, you'll
want to move or delete your local clone and get a new one:

Get a new clone of the fg-download-and-compile-fgmeta team clone on gitorious:

git clone 
git://gitorious.org/+fg-download-and-compile/fg/fg-download-and-compile-fgmeta.git

The team clone can be found at:


http://www.gitorious.org/+fg-download-and-compile/fg/fg-download-and-compile-fgmeta

Information about using the script is at:

http://wiki.flightgear.org/Scripted_Compilation_on_Linux_Debian/Ubuntu

Discussions of changes to the script are at:


http://wiki.flightgear.org/Talk:Scripted_Compilation_on_Linux_Debian/Ubuntu

Tomorrow, I'll request a merge from the team clone to master and next on the 
main fgmeta.

Here's where things stand on the team clone:
  -

master has a copy of the latest approved script version 1.9.11. 
master should be merged to 2.12.0 

next   has a copy of the lastes unapproved script version 1.9.12

Changes on Next:

rebuild command 

When download_and_compile.sh is run, the file 
rebuild 
is placed in the current build directory. 
./rebuild will re-execute  
./download_and_compile.sh with 
the same options it last ran with.

-B option 

The -B allows you to specify a branch as a 
version # 
next, master, 2.12.0, 2.10,0, 2.8.0 are 
supported

-R option 

The R option allows you to select a revision on 
a branch
It defaults to HEAD

-G option 

Allows the selection of a version of OSG
for example -G 3.1.9

The Window title gives information about the build 
while it 
is in progress.  When the build finishes the window 
will indicate 
"Finished Building".  If the build does not finish, the 
Window
title will inidicate where it stopped.

OpenRadar can be built

The version on next is still undergoing testing, Help out by 
trying it and reporting bugs.
Better yet, join the team and make changes on next.







--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Download_and_compile.sh

[Pat]

James and Francesco,

Proposal:

The version of the script on the official fgmeta next, master and
the upcoming release branch and should be maintained and should work.
The same script version can be on each of these branches. Currently
master does not work.  next thinks stable is 2.8.0.

Note that this message is not a request to merge, just a proposal for
how to operate going forward.

Right now in the official fgmeta, we have:

fgmeta  script  script  the script
branch  version status  builds: 
--  --- --  --
next:   1.9.10  (working)   next and 2.8.0
master  1.9.4   (not working)   
2.12.0  1.9.10  (working)   next and 2.8.0
2.10.0  1.9.4   (not working)


in the fgmeta team clone we have:

next:   1.9.tbd working but next, master, 2.12.0,
not fully   2.10.0 2.8.0 
tested  OSG: 3.0.1 and any other
named branch of OSG

master  1.9.11  not releasednext and 2.8.0
untested
minor changes

Suggestion: backport the changes in 1.9.tbd that allows builds of
next,master, 2.12.0, 2.10.0 etc to script version 1.9.11, test it and
release it on Francesco's approval.

or we could just fix 1.9.10

Thoughts?

-Pat

PS. You may be asking how big a change would it be to allow the script
to build basically any branch, tag or commit#


Not too bad:





--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Benchmark matrix

[Pat]

James,

Would fgmeta be an apprporiate spot for this script?


-Pat

On Sat, 22 Jun 2013
14:27:01 -0700 Tom P  wrote:

> Hi,
> 
> While working on performance issues reported by cppcheck, I wanted to
> compare performance to a known baseline and came up with this simple
> test bench.
> It's:
> - written in Python
> - uses the telnet interface to FG
> - doesn't have other dependencies and
> - runs on Linux and Mac (tested) and run on Windows in its first
> incarnation
> 
> The script is called framerate.py and it replays a pre-recorded flight
> (test2.out.gz described here:
> http://wiki.flightgear.org/Suggested_Prerecorded_Flights) while
> collecting numbers on frame rate and maximum latency.
> 
> The repository for this is at :
> https://github.com/flighten/test
> but if there's an option to host this on Gitorious (fg/test ?), I
> would be glad to
> 
>   Tom
> 
> 

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Download_and_compile.sh

[Pat]

James and Francesco,

Proposal:

The version of the script on the official fgmeta next, master and
the upcoming release branch and should be maintained and should work.
The same script version can be on each of these branches. Currently
master does not work.  next thinks stable is 2.8.0.

Note that this message is not a request to merge, just a proposal for
how to operate going forward.

Right now in the official fgmeta, we have:

fgmeta  script  script  the script
branch  version status  builds: 
--  --- --  --
next:   1.9.10  (working)   next and 2.8.0
master  1.9.4   (not working)   
2.12.0  1.9.10  (working)   next and 2.8.0
2.10.0  1.9.4   (not working)


in the fgmeta team clone we have:

next:   1.9.tbd working but next, master, 2.12.0,
not fully   2.10.0 2.8.0 
tested  OSG: 3.0.1 and any other
named branch of OSG

master  1.9.11  not releasednext and 2.8.0
untested
minor changes

Suggestion: backport the changes in 1.9.tbd that allows builds of
next,master, 2.12.0, 2.10.0 etc to script version 1.9.11, test it and
release it on Francesco's approval.

or we could just fix 1.9.10

Thoughts?

-Pat

PS. You may be asking how big a change would it be to allow the script
to build basically any branch, tag or commit#


Not too bad:





--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Download_and_compile.sh

[Pat]

James, 

Eventually I'd like to have a maintainable version on each branch.

What we have in fgmeta master and fgmeta 2.10.0 is script version 1.9.4
The one on 2.8.0 is even older, 1.31.  None of these work, mostly
because of the osg svn url change and maybe other things.  Someone
would have to test to find out.

Script version 1.9.10 which is currently on next does work as is for
next and 2.8.0.  You could merge that version back to master and the
download_and_compile.sh instructions on the wiki will work again.

I can backport the -B and -V options from the new script to a 1.9.11
based on 2.10.0. This minor change would mean the existing script could
support next/master, 2.12.0, 2.10.0, 2.8.0 and maybe even 2.6.0.  

Let me know if you want me to do that.

-Pat





> 
>  BTW - it would obviously be nice to have this file in
> sync with the rest of the 2.12 release.
> 
> James

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Bug#716834: libfltk1.3-dev: --ldflags should contain -ldl

[Pat]

James,

Builds of fgfs and fgrun on next and master are working with this
change.

But this bug is still present when building fgfs and fgrun 2.8.0 and
2.10.0.  

What does the flightgear project do about backporting changes
to previously released versions.  

-Pat

-P.S.  Let me know if you'd like me to update 2.8.0 and 2.10.0 on
personal clones and then submit a merge request.



--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Download_and_compile.sh

[Pat]

An updated version of Download_and_compile.sh is available with
numerous changes.  without specifying version it will build next.  -s
builds 2.8.0.  It can also build 2.12.0, 2.10.0 and 2.8.0, or any other
branch, tag or commit. (-B and -V options.) -D 1 will use a more
efficient directory structure.m-G lets you choose a different version
of OSG.

You can download it from the download_and_compile.sh team share:.

https://www.gitorious.org/+fg-download-and-compile/fg/fg-download-and-compile-fgmeta/blobs/next/download_and_compile.sh

The changes are numerous and significant. 

Francesco Brisa, the maintainer of download_and_compile.sh has not
reviewed the changes so this remains on the tean repo for now.

I'm using this version on a regular basis, but I need others to test
this version and give feedback before I'll ask Francesco to approve it. 

Please let me know if you'd like to help.

-Pat

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Fwd: Re: Bug#716834: libfltk1.3-dev: --ldflags should contain -ldl

[Pat]

The patches as described allowed me to build both fgadmin and fgrun on
Ubuntu 13.10 and on Ubuntu 12.10 

Can someone tell me what the right way to get these changes committed
to next?  Do the maintainers respond best to

1.  a git merge request, 
2.  a git merge request and an email on fg-devel
3   an email on fg-devel with the patches attached 

What's preferred?

Who do we ask for commits to fgfs
Who for fgrun?  gijs?
Is now the right time?  ( builds on Ubuntu 13.04 are broken without
this fix)


-Pat

> 
> This is one way to do it:
> 
> https://gitorious.org/~hof/fg/hof-flightgear/commit/d379698b72d0191d98e5c2f14cf049415b867c0b
>  
> <https://gitorious.org/%7Ehof/fg/hof-flightgear/commit/d379698b72d0191d98e5c2f14cf049415b867c0b>
> 
> Patch checks if the system supports libdl and if so, adds it to the 
> library list.
> 
> Cheers,
> Hof
> 

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Fwd: Re: Bug#716834: libfltk1.3-dev: --ldflags should contain -ldl

[Pat]

The patches as described allowed me to build both fgadmin and fgrun on
Ubuntu 13.10


Go ahead and merge these to next and I'll test again tomorrow.

-Pat

 On Sun, 14 Jul 2013 10:17:02 +0200 Roland Haeder
 wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hello developers,
> 
> can you please include the fix Aaron (thank you for your help) is
> suggesting?
> 
> Best regards,
>   Roland
> 
> -  Original Message 
> Subject: Re: Bug#716834: libfltk1.3-dev: --ldflags should contain -ldl
> Date: Sat, 13 Jul 2013 22:08:42 -0400
> From: u...@debian.org (Aaron M. Ucko)
> To: r.hae...@web.de
> CC: 716834-d...@bugs.debian.org
> 
> Source: fltk1.3
> Version: 1.3.2-3
> 
> r.hae...@web.de writes:
> 
> > the named package should contain -ldl for linking this library with
> > programs. If this flag is absent, I get the following error 
> > message:
> > 
> > /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libfltk.a(Fl_x.o): undefined
> > reference to symbol 'dlsym@@GLIBC_2.2.5'
> 
> That indicates that you've explicitly requested static linkage, in
> which case I would recommend substituting fltk-config
> --ldstaticflags, whose (slightly redundant) output includes -ldl:
> 
> $ fltk-config --ldstaticflags
> /usr/lib/x86_64-linux-gnu/libfltk.a -lXext -lXft -lfontconfig
> - -lfontconfig -lXinerama -ldl -lm -lX11
> 
> I appreciate your interest in the package, and am sorry you ran into
> trouble.
> 
> - --
> Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
> http://www.mit.edu/~amu/ |
> http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
> 
> 
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
> 
> iEYEARECAAYFAlHiXn4ACgkQty+BhcbHvXh2SgCePUtzoieQU+9VZbk9FPcJV26Q
> 0x8An1WzTkrseA50yWdvRIFQN+C5iATP
> =F432
> -END PGP SIGNATURE-
> 
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel


--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Fwd: Re: Bug#716834: libfltk1.3-dev: --ldflags should contain -ldl

[Pat]

Will test tonight or tomorrow on Ubuntu 13.04
-P
On Mon, 15 Jul 2013
20:51:13 -0400 Pat  wrote:

> 
> We'll need a similar fix for fgrun.
> 
> On Sun, 14 Jul 2013 15:25:33 -0400
> Erik van het Hof  wrote:
> 
> > 
> > This is one way to do it:
> > 
> > https://gitorious.org/~hof/fg/hof-flightgear/commit/d379698b72d0191d98e5c2f14cf049415b867c0b
> >  
> > <https://gitorious.org/%7Ehof/fg/hof-flightgear/commit/d379698b72d0191d98e5c2f14cf049415b867c0b>
> > 
> > Patch checks if the system supports libdl and if so, adds it to the 
> > library list.
> > 
> > Cheers,
> > Hof
> > 

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Fwd: Re: Bug#716834: libfltk1.3-dev: --ldflags should contain -ldl

[Pat]

We'll need a similar fix for fgrun.

On Sun, 14 Jul 2013 15:25:33 -0400
Erik van het Hof  wrote:

> 
> This is one way to do it:
> 
> https://gitorious.org/~hof/fg/hof-flightgear/commit/d379698b72d0191d98e5c2f14cf049415b867c0b
>  
> 
> 
> Patch checks if the system supports libdl and if so, adds it to the 
> library list.
> 
> Cheers,
> Hof
> 

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Lots of Progress on Download_and_compile.sh

[Pat]

The next branch on the team clone has the changes to download and
compile.sh listed below. There are just a couple of things left to do,
plus extensive testing.

I gave up on trying to do small incremental changes to the script.
There would be too many variations to test if what I wanted to
accomplish were done in small steps. 

its all available here:

https://www.gitorious.org/+fg-download-and-compile/fg/fg-download-and-compile-fgmeta/blobs/next/download_and_compile.sh

Initial testing is complete
Variant builds work well and flightgear/fgcom/fgrun all start
and run as expected.
I've used it with -G 3.1.9 and it built.  It remains
to be proven that it actually built using OSG-3.1.9 or 3.0.1 as usual.. 

Try your favorite combinations of parameters and let me know how things
work for you.

Remember this is an alpha version.  Not yet approved for general use.

Suggestions:  
  put download_and_compile.sh in a new directory, away from
  your current build

  create a subdirectory and run ../download_and_compile.sh
  from there.

 -Pat

Recently added options:

-G  OSG version number
-B  Version # for Flightgear and Simgear, should
correctly resolve version for openrti
-R  sets a revision for Flightgear and Simgear

-D 1 Directory management option (reduces disk space, clutter,
  and network usage
-N x -DSG_SVN_CLIENT=$OPTARG
-g may actually work
-w verbose makefile
-x sets -x
-v sets -v

Here's what I have been working on.  The next branch has most of this
working.
0.  Change the title of the window in which the build is run
Indicate what variant is being worked on and which component 
is currently being built.

1.  Timestamped log files with or without -x, -v or -xv

2.  Build any of next, master, 2.10.0, 2.8.0 
2a. Build with any git tag.  
2b. If building only one part, such as flightgear, simgear or
openrti, you can specify a commit #.
 

3.  Build the old way and get the same simple directory
structure 

Variant builds are done as usual in separate directories which
contain the entire flightgear component trees including fgdata.

4.  a rebuild script is left in the build directory.  
Executing it will rerun Download_and_compile.sh with the same
options. The script documents what was built and the final
status of the most recent build.

5.  Support for personal and team clones on gitorious.

6.  Build a new way and get a directory structure:

Variant builds are still done in separate directories,
but contain only the variant's build and install directories

A parent directory, above the variant build directories 
contains 
 
fgsrc: sources for flightgear, openrti, simgear, fgrun,
fgcom, fgcomgui etc

othersrc: sources for OSG (mulitple versions
supported), sources for plib (version 1.8.5 supported)

containers for different versions of fgdata:

fgdata_2.12.0, fgdata_2.11.0, fgdata_2.10.0, fgdata_2.8.0 etc.

This new directory structure supports:

1.  No more multiple downloads of fgdata for each
separate build. You download only one, and if you need
more than one version, it is created locally with copy
and git commands. All variant builds use a copy of
fgdata from a parent directory

 2. No more multiple download and builds of plib and
osg. You download and build plib-1.8.5 and osg-3.0.1
once.

 3. A single copy of flightgear, simgear and openrti
sources that can be used to build whatever versions are
needed 

 4. Support for additional versions of osg such as 3.1.9

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FG 2.12 RC Broken ?

[Pat]

> I am assuming that the script will be
> mainly used by people with little interest in the code itself, but
> just want a cutting edge build because they want to test features or
> develope planes and scenery for it.

not necessarily.  I'm interested in the capability of doing multiple
builds with different versions, branches and options and in doing some
kind of automated testing on the resulting builds
Can't do that without being interested in code ;-)

but in the main, you are probably right.


-Pat

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FG 2.12 RC Broken ?

[Pat]

Thanks Tom.

With the current version of download_and_compile.sh any installed
version of OSG is ignored in favor of one built by the script.  This
raises a point we may want to consider:  If the desired version of OSG
for a given build is installed, why build it?

-Pat

 Mon, 1 Jul 2013 13:39:44 +0200 Thomas Geymayer
 wrote:

> 2013/7/1 Pat :
> > and when you do, there will be a download_and_compile.sh version to
> > support it..
> 
> There should be no need to change anything. During compile time the
> installed OSG version is automatically detected and the according
> version of the API is used. So for OSG < 3.1.8 nothing should have
> changed.
> 
> Tom
> 
> --
> This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FG 2.12 RC Broken ?

[Pat]

> Actually we can fix that a little better, and detect the OSG version
> at compile time. I will need to check exactly which #ifdefs are
> needed for that.
> 
> James
> 

and when you do, there will be a download_and_compile.sh version to
support it..


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] New alpha version of download_and_compile.sh - avoids multiple fgdata downloads.

[Pat]

Any date or version will serve.

Here's how to do it:

1. Create a new work directory for fg builds you are going to use the
next/experimental version on. Mine is ~/work/fg

2. In the new work directory, place a copy of the experimental
download_and_compile.sh

3. Create directories for the versions of fgdata you are going to need:

~/work/fg/fgdata_2.11.0
~/work/fg/fgdata_2.10.0
~/work/fg/fgdata_2.8.0

Depending on how much you like to test, you can create just one
of these and copy -R your downloaded copy into it. Or you can
copy -R into all three. The script should be able to handle it
either way. Also, it should not matter which version you put in
these directories. The script should be able to reset them to
the right version when a build is done for that version.

So far, everything is in your new work directory.  Builds
happen one level down.

4.  Create a directory for the build you want to do

~/work/fg/master
~/work/fg/next
~/work/fg/stable
~/work/fg/2.10.0
~/work/fg/2.8.0

5.  cd to the directory you want to build and do the right build

for example:


cd ~/work/fg/next
../download_and_compile.sh -p n -d y -xv all

cd !/work/fg/2.10.0
../download_and_compile.sh -p n -d y -xv j 3 -B 2.10.0 -R HEAD all

Now if you have to blow away one of your build directories, fgdata stays
put, safe and sound in the top of your fg work tree.

I'm taking bets on how long it takes you to find a bug...  Happy
hunting.

-Pat

> ..to avoid the 3-day delay fetching a new 5GB copy of fgdata, 
> where do I put my "March 29'th-current" copy of fgdata?
> I now have it as 2.11.0 in ~/FG-git/fgdata 
> 


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] New alpha version of download_and_compile.sh - avoids multiple fgdata downloads.

[Pat]

I've put a new version of download_and_compile.sh on the team clone 

http://www.gitorious.org/+fg-download-and-compile/fg/fg-download-and-compile-fgmeta/blobs/next/download_and_compile.sh

The big change:

This version changes the way fgdata is handled to prevent
multiple downloads of the 5G of git archives for fgdata.
Multiple versions of fgdata can be kept active and up to date
for testing purposes.  Various build and install trees can be
created using download_and_compile.sh. Each of these will use
symlinks to the appropriate fgdata version.

This is an alpha version 

It has not been approved for the main tree.

It has had some testing, but needs others to try it out to
uncover any bugs.  I recommend using it in a separate directory
from your usual builds until you have some confidence in how it
works.  

If you find a bug, create a detailed log by running it like this:

./download_and_compile.sh -xv >download_and_compile_diagnostics.log

This log is likely to be large.  Please don't e-mail it to the
list.

Instead, Email me, find me on irc #flightgear as user pac1 or
contact me through the flightgear forum.  If you've got my
phone #, feel free to use it.

Here's the commit note for the change:

Add -D option to change the handling of fgdata

With this change a download_and_compile.sh user can optionally
use a single copy of fgdata as a base for builds using any
other version.

The -D option will find and create if not found, version
directories for fgdata.  Once this is done for one version,
download_and_compile.sh will use these directories to prevent
multiple downloads of the entire 5gb git archive, when a
different version of fgdata is needed.  The directories are
initially placed at the same level as download_and_compile.sh.
The directories can be moved higher in the directory tree if
desired.

When an existing or new build and install tree needs to use a
particular version of fgdata, a symlink in fgfs/install will
connect the build to the correct version.  If the correct
version does not yet exist it will be copied from an existing
fgdata of another version and changed to the needed version
using git checkout.

This allows download_and_compile.sh to create as many build and
install trees as desired, each with different versions and
options, while keeping network usage to a minimum.

a typical set of fgdata and separate build directories  might
look like:

~/work/fg
~/work/fg/fgdata_2.8.0
~/work/fg/fgdata_2.10.0
~/work/fg/fgdata_2.11.0
~/work/fg/master
~/work/fg/master-openrti-debug
~/work/fg/stable
~/work/fg/2.10.0-debug

for each build, the required symlink will be created to the
corresponding fgdata_* directory.

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] download_and_compile.sh and CMake Superbuild discussion

[Pat]

Pat Callahan and James Turner had an irc converation today about
building flightgear. Here is Pat's summary of the main points

Ongoing changes to Download_and_compile.sh

Pat's goal is to increase the functionality of the script
without changing the way it is used for simple builds of 
master/next or stable builds.

these changes can be seen on the team clone Pat is using for
download_and_compile.sh maintenance. Let Pat or Francesco know
if you want to join the team in any capacity.


https://www.gitorious.org/+fg-download-and-compile/fg/fg-download-and-compile-fgmeta

The changes on the team clone are pretested, but may still
contain bugs.  1.9.10 is very well tested. 1.9.11 is ready for
has only minor changes. next has had some testing but could
use a serious workout.

Francisco will approve all changes that are to be merged with
the main fgmeta tree.  

Francesco has approved 1.9.10 and 1.9.11 for merging into the
master fgmeta tree, but has yet to see and approve next 
next has additional details on pat's future versions
beyond next starting at line 54.

download_and_compile.sh version number:

James thought the version numbers for download_and_compile
might be confusing.  They're different from the versions for
    flightgear.  Pat thinks we could put a working version on each
branch that is tested to work with that specific branch, with
a version number to match the flightgear version on the branch.
We might want to make a rule that next should always support
next, master and the previous 2 releases.

Pat will bring the script version issue up with Francesco.


The cmake superbuild:

James thought that a cmake superbuild could do most if not all
of the basic functions of the script.  Pat likes the idea and
thinks it can be integrated with the script or used
independently. 

The superbuild approach could be used without a script to do a
simple build on any platform, while download_and_compile.sh
wuld provide additional options not easily provided by cmake.

If the superbuild had enough additional logic built into it it
could also do more complex and more efficient build scenarios
and could be the build engine for most flightgear components in
download_and_compile.sh

James goal of a simple build method for any platform would
still be met.  The additonal logic and variables in the
CMakeLists.txt would be there, but most users would never need
to examine it.

Basic Instructions should look something like this:

wget \
http://www.gitorious.org/fg/fgmeta/blobs/raw/next/CMakeLists.txt

cmake -D.FGVERSION="2.10.0" ./

make

The cmake file is incomplete at this point, and this build
fails to install because its trying to
use /usr/local/lib/i386-linux-gnu without admin privs

-Pat

--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] new team clone on gitorious.org specifically for download_and_compile.

[Pat]

On Sat, 01 Jun 2013 10:16:10 +0100
James Turner  wrote:

> 
> On 1 Jun 2013, at 04:00, Pat  wrote:
> 
> > I created a new team clone of fgmeta on gitorious.
> 
> I'm a little confused by the need for the fgmeta clone - but of
> course delighted to have people working on the compile script. Why
> don't we simply add the script to the fg fgmeta repository and
> maintain it there?
> 

It's already in the fgmeta repository as version 1.9.4.  

Since I don't expect to get commit rights in the main tree,  I created
a team clone. I thought that might be the right way to do things.
They're easy enough to get rid of if we don't need one.

 CMake superbuilds using fgmeta. 

That's one of the ideas being floated on the wiki.  I'll do
some reading on this and try to write it up for the wiki article on
scripted compilation. 

-Pat

I thought this might be appropriate: 
"There is another system..." http://www.youtube.com/watch?v=3R6COGKX8ws


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] new team clone on gitorious.org specifically for download_and_compile.

[Pat]

Francesco,

I created a new team clone of fgmeta on gitorious.

https://www.gitorious.org/+fg-download-and-compile/fg/fg-download-and-compile-fgmeta

I took 1.9.10 and made a small correction for the c option and pushed
it to the clone.  then I did a merge request for master.  We'll see how
that plays out.

The merge request note is shown here.


Reviewing merge request #1: Version Bump with numerous changes 1.9.4 to
1.9.10

Francesco approved this change for release, and I wanted to get it into
the master to replace the one that's there, 1.9.4. 1.9.4 is out of date
and won't work without some of the changes in 1.9.10

I'm not sure where the versions from 1.9.5 through 1.9.9 are at. I
don't have copies or I would have started with them to give a complete
record of the changes. If copies of them turn up, we can always put
them on master in the correct order.. Francisco may have sent these to
Thorsten B.

Anyway, I created a team repository for the sole purpose of maintaining
download_and_compile.sh. I'll get Francesco on as soon as he has time
for it and will authorize anyone else who wants in to help maintain the
team clone.

Francesco is ok with me handling the commits, but he will still approve
any changes. He's approved changes through 1.9.11

In the meantime, he's approved the changes in this version and in the
next version 1.9.11, which I'll request after this merge is approved
and completed..

Feel free to discuss this on flightgear-devel or in the posts for this
merge request.

Requested by: avatar pac1
Status: Open
Source repository: fg-download-and-compile-fgmeta:1.9.10
Target repository: fgmeta:master
Created at: June 1st, 2013 02:53


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] FGRUN build fails with CMake Error at CMakeLists.txt:228 (message): FLTK 1.3 is required

[Pat]

You may have heard there is a problem building FGRUN on Ubuntu 13.04 but
not on Ubuntu 12.10.  I've attached a patch to fgrun/CMakeLists.txt.  I
consider it a workaround. It's been tested on 13.04 and 12.10

The symptom:

  The build on Ubuntu 13.04 fails with the message:
  -- Performing Test HAVE_FLTK_1_3 - Failed
  CMake Error at CMakeLists.txt:228 (message):
FLTK 1.3 is required

  The message appears on a freshly installed and updated
  installation of 13.04, after adding the additional packages
  needed to build flightgear.

  There is no earlier version of FLTK installed.  Other than
  install the tools needed to build flightgear, nothing unusual
  has been done to the libraries.

The problem:

  The failure happens when CMake tries to check that a compile
  and link using fltk 1.3 succeeds.  The compile and link
  fails  

  This is the failing section of code from fgrun/CMakeLists.txt
  at the indicated point, line 228.

   check_cxx_source_runs(
  "#include 
  int main() {
  return Fl::version() >= 1.03 ? 0 : -1;
  }
  "
  HAVE_FLTK_1_3)

if ( NOT HAVE_FLTK_1_3 )
message( SEND_ERROR "FLTK 1.3 is required" ) 
endif ( NOT HAVE_FLTK_1_3 )
Analysis:

  The compile of the code in the above CMakeLists.txt code is
  failing, presumably because it does not have -ldl in the path.
  
  Commenting out this section of the CMakeLists.txt allows the
  build for FGRUN to proceed.  However with only this change,
  the actual build fails during the link phase of FGRUN for the
  same reason.  Running the cmake and make in verbose mode
  gives the actual error and illustrates the problem.

  you get undefined reference to symbol dlopen@@GLIBC_2.1
  this is in libdl.so

Possible Causes:

  1. Sometething is amis with fltk and cmake. Has a library has
  moved out of reach of the Find_FLTK.cmake.  

  2. Installing something broke it on Ubuntu 13.10. 

Workaround:

  Our CMakeLists.txt for FGRUN builds the variable
  FLTK_LIBRARIES. I added  "libdl.so" to this variable
  before adding two additional libraries needed for fltk. This
  fixes the build, but not the test for fltk version 1.3 in the
  cmake. Commenting out this test seems an acceptable
  workaround and the build works.
Testing:
I have tested the patch on Ubuntu 13.04 and Ubuntu 12.10.  As
long as FLTK 1.3 is installed everything should work. 

# get rid of previous build and install for fgrun
rm -rf build/fgrun install/fgrun

# get fresh copy of CMakelists.txt
./download_and_compile.sh -d y -p n fgrun 

patch fgrun/CmakeLists.txt <0001.patch-fgrun-CMakeLists.txt

# build without downloading a fresh CMakeLists.txt -note  -d n

./download_and_compile.sh -d n -p n fgrun 


Next Steps:

If acceptable, Commit the patched fgrun/CMakeLists.txt

It would be good if someone can come up with a better patch,
one that allows the check_cxx_source_runs to do its test.

If anyone has a good explanation of what is really going on
with fltk and change between the two versions, I'd like to see
it.  We are not the only application with this issue.

ask the fltk maintainers about this

_pat
--- CMakeLists.txt.old  2013-05-23 22:26:42.532784855 -0400
+++ CMakeLists.txt  2013-05-23 22:01:45.988781967 -0400
@@ -202,6 +202,7 @@
 endif ( NOT ( HAVE_OPENPTY OR HAVE__GETPTY ) )
 
 if ( FLTK_FOUND )
+ list(APPEND FLTK_LIBRARIES "libdl.so")
 if ( X11_Xinerama_FOUND )
 message(STATUS "Found X11_Xinerama...")
 list(APPEND FLTK_LIBRARIES ${X11_Xinerama_LIB})
@@ -216,17 +217,17 @@
 set( CMAKE_REQUIRED_LIBRARIES ${FLTK_LIBRARIES} )
 message(STATUS "Using FLTK_LIBRARIES for fgrun: ${FLTK_LIBRARIES}")
 
-check_cxx_source_runs(
-"#include 
-int main() {
-return Fl::version() >= 1.03 ? 0 : -1;
-}
-"
-HAVE_FLTK_1_3)
-
-   if ( NOT HAVE_FLTK_1_3 )
-   message( SEND_ERROR "FLTK 1.3 is required" ) 
-   endif ( NOT HAVE_FLTK_1_3 )
+#check_cxx_source_runs(
+#"#include 
+#int main() {
+#return Fl::version() >= 1.03 ? 0 : -1;
+#}
+#"
+#HAVE_FLTK_1_3)
+#
+#  if ( NOT HAVE_FLTK_1_3 )
+#  message( SEND_ERROR "FLTK 1.3 is required" ) 
+#  endif ( NOT HAVE_FLTK_1_3 )
 
 endif ( FLTK_FOUND )
 
--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the o

[Flightgear-devel] Who is the maintainer for FGRUN?

[Pat]

Who is the maintainer for FGRUN?

Also, who is interested in the cmake build issue
with FGRUN and FGADMIN on Ubuntu 13.04

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] OpenRTI / HLA

[Pat]

if you put the library files outside of x86_64-linux-gnu
and x86_32-linux-gnu you would not be able to tell if the files are for
32 or 64 bit.  That directory is part of the multi-arch specification.
I don't think we want to take it out.

Can this be fixed in the CMakeLists.txt?
Is that the right solution?

-Pat

On Mon, 18 Mar 2013 00:41:03 +0100
Clement de l'Hamaide  wrote:

> Mathias,
> 
> > Thanks, I have moved the rti libs below the simgear ones.
> Does this help?
> 
> Yes it works fine now ! Thanks you.
> But a new mistake appers now, FG is not able to found libRTI-NG.so.1
> because the file is in
> install/openrti/lib/x86_64-linux-gnu/libRTI-NG.so.1 I've fixed the
> problem by moving all files outside of x86_64-linux-gnu/ directory
> and now it works.
> 
> Is it possible for you to change the CMakeLists.txt in order to
> change the path like install/openrti/lib/libRTI-NG.so.1  ? We had a
> similar problem some weeks ago about libsvn/subversion :
> 
> http://code.google.com/p/flightgear-bugs/issues/detail?id=946#c10
> https://www.gitorious.org/fg/flightgear/commit/3b6436bfb8d5cfb180f7119fd01f365d1f79528e
> 
> Thanks you,
> Clément
> 

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] OpenRTI / HLA

[Pat]

I ran a clean build of master/next using download_and_compile.sh -ei and
everything under fgfs/flightgear built including fgviewer.

Smoke test: Run with C172P at KSFO, takeoff for a run to half moon bay.
Multiplayer working.

So what needs testing with HLA?

-Pat

On Sun, 17 Mar 2013 15:30:47 +0100
Mathias Fröhlich  wrote:

> 
> Hi,
> 
> On Thursday, March 07, 2013 18:26:46 Clement de l'Hamaide wrote:
> > Mathias, some weeks ago I told you about a compilation problem for
> > FG on Linux when RTI is enabled. You asked me to remind you of this
> > problem later, this day is came :)
> 
> Thanks, I have moved the rti libs below the simgear ones.
> Does this help?
> 
> Greetings
> Mathias


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] 2.10.1

[Pat]

what's the relationship between 
2.10.0
the maint branch
and 2.10.1?


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] OpenRTI / HLA

[Pat]

Now my question is what adjustments need to be made to cause cmake to
put the openrti libs in the right place in the link, after the simgear
libraries.

The problem with fgviewer builds is exhibited by its compile command,
found in the build tree at
build/fgfs/utils/fgviewer/CMakeFiles/fgviewer.dir/link.txt

it is invoked during the cmake as:
cd /home/pac1/build/master/build-maint-ei/fgfs/utils/fgviewer #
&& /usr/bin/cmake -E cmake_link_script CMakeFiles/fgviewer.dir/link.txt
--verbose=1

adapt the above to your build and try it.  Does it fail?

In link.txt, LibRtI-ng.so and libFedTime.so are in the link list BEFORE 
libSimGearScene.a libSimGearCore.a

moving these two items AFTER the libSimgear static libraries makes the
link work:


-rdynamic 
/home/pac1/build/master/install-maint-ei/openrti/lib/i386-linux-gnu/libRTI-NG.so
 
/home/pac1/build/master/install-maint-ei/openrti/lib/i386-linux-gnu/libFedTime.so



Note that it does it right for the fgfs executable but does it wrong
for the fgviewr executable.


unchanged and modified link.txt files are attached.



-Pat

 LIOn Thu, 07 Mar 2013 18:26:46 +0100 Clement de l'Hamaide
  wrote:

> 
> Hi,
> 
> Mathias, some weeks ago I told you about a compilation problem for FG
> on Linux when RTI is enabled. You asked me to remind you of this
> problem later, this day is came :)
> 
> For remembering :
> 
> > Clement wrote :
> >> I'm really interested by your work about OpenRTI / HLA. I've added
> >> the RTI
> 
> >> support in the download_and_compile.sh brisa script's in order to
> >> make it
> 
> >> more "user-friendly" to use and participate to the development. I
> >> compile
> 
> >> SG and FG with -DENABLE_RTI=ON since some weeks but today FG
> >> compilation
> 
> >> crashed with this option :/ Here is the compilation log :
> 
> >> http://pastebin.com/HnPSfyzs
> 
> >> OpenRTI and SG compilation are fine. I've deleted my OpenRTI/FG/SG
> >> build dir
> 
> >> but the issue still here. Do you have a solution ?
> 
> > Remind me to look at that past the Christmas days please.
> 
> Today I gave a new try but the compilation still fails :
> http://pastebin.com/grfbW2SG SG compilation works fine with
> ENABLE_RTI=ON  but FG compilation fails with it. Can you take a look
> at it ? Let me know if you need more info, also I can make some
> change in source code if you tell me what to change.
> 
> Cheers,
> Clément
> 
> 
> 
> 
> 
/usr/bin/c++   -O3 -D__STDC_CONSTANT_MACROS -Wall  -D_REENTRANT 
-DBOOST_MULTI_INDEX_DISABLE_SERIALIZATION -DBOOST_BIMAP_DISABLE_SERIALIZATION 
-O3 -DNDEBUG CMakeFiles/fgviewer.dir/fgviewer.cxx.o 
CMakeFiles/fgviewer.dir/Drawable.cxx.o CMakeFiles/fgviewer.dir/Renderer.cxx.o 
CMakeFiles/fgviewer.dir/SlaveCamera.cxx.o CMakeFiles/fgviewer.dir/Viewer.cxx.o 
CMakeFiles/fgviewer.dir/HLACamera.cxx.o 
CMakeFiles/fgviewer.dir/HLACameraClass.cxx.o 
CMakeFiles/fgviewer.dir/HLACameraManipulator.cxx.o 
CMakeFiles/fgviewer.dir/HLADrawable.cxx.o 
CMakeFiles/fgviewer.dir/HLADrawableClass.cxx.o 
CMakeFiles/fgviewer.dir/HLAEyeTracker.cxx.o 
CMakeFiles/fgviewer.dir/HLAEyeTrackerClass.cxx.o 
CMakeFiles/fgviewer.dir/HLAMPAircraft.cxx.o 
CMakeFiles/fgviewer.dir/HLAMPAircraftClass.cxx.o 
CMakeFiles/fgviewer.dir/HLAOrthographicCamera.cxx.o 
CMakeFiles/fgviewer.dir/HLAOrthographicCameraClass.cxx.o 
CMakeFiles/fgviewer.dir/HLAPerspectiveCamera.cxx.o 
CMakeFiles/fgviewer.dir/HLAPerspectiveCameraClass.cxx.o 
CMakeFiles/fgviewer.dir/HLAPerspectiveViewer.cxx.o 
CMakeFiles/fgviewer.dir/HLAPerspectiveViewerClass.cxx.o 
CMakeFiles/fgviewer.dir/HLARenderer.cxx.o 
CMakeFiles/fgviewer.dir/HLARendererClass.cxx.o 
CMakeFiles/fgviewer.dir/HLASceneObject.cxx.o 
CMakeFiles/fgviewer.dir/HLASceneObjectClass.cxx.o 
CMakeFiles/fgviewer.dir/HLAView.cxx.o 
CMakeFiles/fgviewer.dir/HLAViewClass.cxx.o 
CMakeFiles/fgviewer.dir/HLAViewer.cxx.o 
CMakeFiles/fgviewer.dir/HLAViewerClass.cxx.o 
CMakeFiles/fgviewer.dir/HLAViewerFederate.cxx.o 
CMakeFiles/fgviewer.dir/HLAWindowDrawable.cxx.o 
CMakeFiles/fgviewer.dir/HLAWindowDrawableClass.cxx.o  -o fgviewer \
-rdynamic 
/home/pac1/build/master/install-maint-ei/openrti/lib/i386-linux-gnu/libRTI-NG.so
 \

/home/pac1/build/master/install-maint-ei/openrti/lib/i386-linux-gnu/libFedTime.so
 \

/home/pac1/build/master/install-maint-ei/simgear/lib/i386-linux-gnu/libSimGearScene.a
 \

/home/pac1/build/master/install-maint-ei/simgear/lib/i386-linux-gnu/libSimGearCore.a
 \

/home/pac1/build/master/install-maint-ei/simgear/lib/i386-linux-gnu/libSimGearCore.a
 \
-rdynamic 
/home/pac1/build/master/install-maint-ei/openrti/lib/i386-linux-gnu/libRTI-NG.so
 \

/home/pac1/build/master/install-maint-ei/openrti

Re: [Flightgear-devel] download_and_compile.sh one git repository or serveral.

[Pat]

I thought there would be a benefit to moving fgdata out from under
${CBD}/install. Currently, if you do mulitple builds with different
options in different folders, you end up with multiple copies of the
same version of fgdata, even though a related build has a perfectly
good copy.


I've got it set up like this:

build/
download_and_compile.sh
fgdata-2.11.0
fgdata
fgdata-2.10.0
fgdata
master  
install
fgfs
fgdata symlink

stable
install
fgfs
fgdata symlink

stable-e
install
fgfs
fgdata symlink
stable-ei 
etc.

I'm trying this out and will send a patch when its working right.

-Pat

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] download_and_compile.sh one git repository or serveral.

[Pat]

On Mon, 25 Feb 2013 12:19:54 +0100
Stefan Seifert  wrote:

> On Sunday 24 February 2013 22:18:05 Pat wrote:
> 
> > > > Anders made a suggestion on IRC I'm going to follow up on. "
> > > > You can have local git clones that share the same .git/* files
> > > > via file links"
> > > 
> > > ..you feed 4 build trees from 1 git clone, how?
> > > A "du -sch $git-n-build-trees" on them all? - Arnt
> 
> You probably don't want to symlink all the files in .git. You just
> want to symlink the objects subdirectory. This is the place where all
> the real data is and it would be the same for all local repositories.
> The other files list for example branches and tags and very
> important: the currently checked out branch. So if you want several
> local repositories with different branches checked out, you may not
> share these files.
 
> Stefan

Thanks! With the one above, and one each from Anders and James, I now
have three good suggestions with two alternative new approaches to look
into.  

However this may all be moot unless the new approaches save
considerable time and effort down the road.  I'm not sure they would
so I'm not going to pursue them at this time.

My original purpose was to avoid  cloning from git for each test build.
I'm using download and compile.sh to create builds for several sets of
option combinations.  Do this for more than one version and you end up
with more than enough complete copies of git to satisfy an army of
coders.

This wastes bandwidth on gitorious. 

I'm thinking that one local git for each version (next, master, maint &
2.10.0 ) is simple enough.  Its four copies of git but that's not too
bad... I can make change to the script to allow concurrent separate
builds with different options off these separate gits without too much
change.

The single git method could come later if anyone thinks it's worth
doing.
 

 -Pat

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] download_and_compile.sh one git repository or serveral.

[Pat]

> > patch-1.9-8-xv.patch adds the x and v options for debugging.  

> > patch-1.9-8-w.patch adds the w option, w standing for "Where to
> > Build"
> > patch-1.9-8-wxv.patch combines both changes.
> 
> ..alongside those, I like to see _what_ I build|t _when_, so I
> auto-rename my logs, and I believe "-s" should build 2.10 now:
> arnt@celsius:~/FG-git$ ll download_and_compile-1.9-8a.patch \
> &&md5sum download_and_compile-1.9-8a.patch 
> -rw-r--r-- 1 arnt arnt 1441 Feb 24 23:24
> download_and_compile-1.9-8a.patch 
> a342d108f121322f076ef7de063ab1e4  download_and_compile-1.9-8a.patch
> arnt@celsius:~/FG-git$ 
> 
how about two types of logging:
1. Timestamped record of the start,finish and status of
   each run
2. full log with logrotate feature


> > Anders made a suggestion on IRC I'm going to follow up on. " You can
> > have local git clones that share the same .git/* files via file
> > links"
> 
> ..you feed 4 build trees from 1 git clone, how?  
> A "du -sch $git-n-build-trees" on them all?  
> 
 I'm just learning how to work with git, one
baby step at a time.  I'm sure the suggestion is valid.  My
interpretation of it may not be.

>From what I'm reading its possible to have multiple source trees
working off one git repository.  You'd do the git operations as usual.
Again, I'm not sure how all this works but I'm learning.

Does anyone have a script for something like this for any application?


> > I think that means we could have several local clones of a single
> > local git repository.  The various local clones would support
> > building multiple branches and  versions, without having to sync
> > each clone independently with gitorious.
> 
> ..you only do an e.g. "git branch 2.10 ;git checkout", 
> and no "git pull"???
> 
Its a good bet the usual git operations will apply.

Thanks
Pat

There's an old joke about a city guy asking a farmer how to get to a
nearby town.  The farmer looks at him with a straight face and replies
"You can't get there from here".  I'm the city guy.



--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] download_and_compile w, x and v options

[Pat]

Here are two patches and a combined patch for both.
These patches include changes to the help.

patch-1.9-8-xv.patch adds the x and v options for debugging.  

patch-1.9-8-w.patch adds the w option, w standing for "Where to Build"

patch-1.9-8-wxv.patch combines both changes.

I'm in the process of working out how to do a variety of builds
for testing the download and compile script.  The x and v options help
in that regard.  

The w option allows me to test different download_and_compile builds
with different options in different directories from a single copy of
download_and_compile.sh

Like so:

download_and_compile.sh -w master ALL 
download_and_compile.sh -w master_e -e ALL # new event model
download_and_compile.sh -w master_r -r ALL # openrti
download_and_compile.sh -w master_er -er ALL # both

However just using a different directory is a bit inefficient.  It
results in multiple copies of git that are separate clones of the
gitorious repository.

Anders made a suggestion on IRC I'm going to follow up on. " You can
have local git clones that share the same .git/* files via file links"

I think that means we could have several local clones of a single local
git repository.  The various local clones would support building
multiple branches and  versions, without having to sync each clone
independently with gitorious.

The script would still work just as well for someone who just wanted to
compile a single version

-Pat

Note for those reading on the devel list, the patches are based on
download_and_compile.sh version 1.9-8, as of today, that's available
from http://assistenza.larasrl.net/brisa/fgfs/download_and_compile.sh





--- download_and_compile-1.9-8.sh	2013-02-24 10:23:20.288494978 -0500
+++ download_and_compile-w.sh	2013-02-24 11:45:41.688504514 -0500
@@ -39,6 +39,7 @@
 
 WHATTOBUILD=
 WHATTOBUILDALL=( PLIB OSG OPENRTI SIMGEAR FGFS DATA FGRUN )
+COMPILE_BASE_DIR=.
 UPDATE=
 STABLE=
 
@@ -56,7 +57,7 @@
 WITH_EVENT_INPUT=""
 WITH_OPENRTI=""
 
-while getopts "suhc:p:a:d:r:j:O:gei" OPTION
+while getopts "suhc:p:a:d:r:j:O:geiw:" OPTION
 do
  case $OPTION in
  s)
@@ -98,6 +99,9 @@
  i)
  WITH_OPENRTI="-D ENABLE_RTI=ON"
  ;;
+ w)
+		COMPILE_BASE_DIR=./$OPTARG
+ ;;
 
 
  ?)
@@ -191,6 +195,7 @@
 	echo "* -O XAdd -OX to the make compilation	   default=None"
 	echo "* -r y|n  y=reconfigure programs before compiling them  n=do not reconfigure	default=y"
 	echo "* -s compile only last stable known versions	default=y"
+	echo "* -w run the build in a subdirectory		default=current directory"
 	
 	exit
 fi
@@ -342,18 +347,7 @@
 	echo " OK" >> $LOGFILE
 fi
 
-
-
-
-
-
-
-
-
-COMPILE_BASE_DIR=.
-
-
-
+mkdir -p $COMPILE_BASE_DIR || echo "Unable to create directory $COMPILE_BASE_DIR"
 
 #cd into compile base directory
 cd "$COMPILE_BASE_DIR"
--- download_and_compile-1.9-8.sh	2013-02-24 10:23:20.288494978 -0500
+++ download_and_compile-wxv.sh	2013-02-24 11:42:48.096504179 -0500
@@ -18,8 +18,8 @@
 # along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
 
-VERSION="1.9-8"
-
+VERSION="1.9-8-wxv"
+echo download_and_compile.sh version: $VERSION
 #COMPILE GIT FGFS
 
 ###
@@ -39,6 +39,7 @@
 
 WHATTOBUILD=
 WHATTOBUILDALL=( PLIB OSG OPENRTI SIMGEAR FGFS DATA FGRUN )
+COMPILE_BASE_DIR=.
 UPDATE=
 STABLE=
 
@@ -56,7 +57,7 @@
 WITH_EVENT_INPUT=""
 WITH_OPENRTI=""
 
-while getopts "suhc:p:a:d:r:j:O:gei" OPTION
+while getopts "suhc:p:a:d:r:j:O:geiw:xv" OPTION
 do
  case $OPTION in
  s)
@@ -98,6 +99,15 @@
  i)
  WITH_OPENRTI="-D ENABLE_RTI=ON"
  ;;
+ w)
+		COMPILE_BASE_DIR=./$OPTARG
+ ;;
+ x)
+ set -x
+ ;;
+ v)
+ set -v
+ ;;
 
 
  ?)
@@ -187,11 +197,13 @@
 	echo "* -p y|n  y=download packages n=skip download packages  	default=y"
 	echo "* -c y|n  y=compile programs  n=do not compile programs 	default=y"
 	echo "* -d y|n  y=fetch programs from internet (cvs, svn, etc...)  n=do not fetch 	default=y"
-	echo "* -j XAdd -jX to the make compilation		 	default=None"
-	echo "* -O XAdd -OX to the make compilation	   default=None"
+	echo "* -j XAdd -jX to the make compilation	default=None"
+	echo "* -O XAdd -OX to the make compilation	default=None"
 	echo "* -r y|n  y=reconfigure programs before compiling them  n=do not reconfigure	default=y"
 	echo "* -s compile only last stable known ver

[Flightgear-devel] Questions about download_and_compile.sh

[Pat]

 Questions for those familiar with cmake and download_and_compile.sh: 

1.  Why does the download_and_compile script section for OSG, do
cmake ../../OpenSceneGraph/ 
without any options, followed immediately by 

cmake -D CMAKE_BUILD_TYPE="Release" \
-D CMAKE_CXX_FLAGS="-O3 \
-D__STDC_CONSTANT_MACROS" \
-D CMAKE_C_FLAGS="-O3" \
-D CMAKE_INSTALL_PREFIX:PATH="$INSTALL_DIR_OSG" \
../../OpenSceneGraph/

2.  Why does download_and_compile build simgear and openrti from
sources in simgear/simgear and openrti/openrti 
while OpenSceneGraph is done from sources in OpenSceneGraph,
without the extra sub-directory/folder.

3.  Why does the script only do reconfigure 
if the script is NOT running in update mode? Wouldn't you need
to reconfigure if there were a new module?



-Pat

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] getting the latest download_and_compile.sh

[Pat]

 

http://www.gitorious.org/fg/fgmeta/blobs/raw/master/download_and_compile.sh

this retrieves version 1.9.4

replacing master with next gets version 1.4

Is there a way to wget 1.9.6?

-Pat

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] ..I have openrti seen ok at build time but not at runtime?????, was: ..has anyone tried testing FG build scripts in fresh trees?

[Pat]

When I wrote that OpenRTI builds, I did not realize that
download_and_compile.sh 1.9.4 will build OpenRTI even though the i
option is not set. Without the i option, it never gets used. So forget
anything I've said about this so far. 

I'll send a note to Fancesco to add a condition 
 "! "$WITH_OPENRTI" = "" 

to the part of download_and_compile.sh that builds OpenRTI. 

Meanwhile testing fresh builds continues on 32 bit Ubuntu 12.10

rm -rf master/build
rm -rf master/install
download_and_compile...

-Pat



--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Obsolete weather models and textures

[Pat]

On Sun, 03 Feb 2013 21:07:37 +0100
Geoff McLane  wrote:

> Hi Renk,
> 
> Thank you for the time and effort to produce this list.
> 
> 

Should we think about some kind of tool to find flightgear lint like
this? What would the tool have to do?

Renk,   What steps did
you take to find candidates for deletion and to verify the
weather is not used?

- Pat




--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] ..has anyone tried testing FG build scripts in fresh trees?

[Pat]

libRTI-NG.so.1 should be in test-tree/install/openrti/libRTI-NG.so.1


The following works for me:

#bin/bash
TEST_TREE=$1
if [ "$TEST_TREE" == "" ]
then
TEST_TREE="test-tree"
fi
mkdir -vp test-tree
cd test-tree
wget -c \
http://www.gitorious.org/fg/fgmeta/blobs/raw/master/download_and_compile.sh
sh download_and_compile.sh -j 2 |tee download_and_compile.sh--j-2.log
sh download_and_compile.sh -a n -p n -d n -j 2 ALL |tee \
download_and_compile.sh-a-n--p-n--d-n--j-2-ALL.log

run_fgrun.sh and Flightgear started right 


after the first  download_and_compile.sh, libRTI-NG.so.1 should be in
test-tree/install/openrti/libRTI-NG.so.1

A side note:
$sh download_and_compile.sh. 
will work even without the chmod -x download_and_compile.sh

On Thu, 31 Jan 2013 07:25:39 +0100
Arnt Karlsen  wrote:

> Hi,
> 
> ..has anyone tried testing FG build scripts in fresh trees?
> 
> ..as in, "mkdir -vp test-tree ;cd test-tree ;wget -c \
> http://www.gitorious.org/fg/fgmeta/blobs/raw/master/download_and_compile.sh
> ;chmod -x download_and_compile.sh  ;\
> sh download_and_compile.sh -a n -p n -d n -j 2 ALL ", like our recipe:
> http://wiki.flightgear.org/Scripted_Compilation_on_Linux_Debian/Ubuntu
> says is possible?  I get errors, the weird part is I can "prime" my
> test tree, and then most parts of download_and_compile.sh works, e.g.
> plib, openrti, OSG, SG and FG all builds ok, but FG bombs right out:
> ./run_fgfs.sh
> ./fgfs: error while loading shared libraries: libRTI-NG.so.1: cannot
> open shared object file: No such file or directory
> 
> 


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Sync with JSBSim

[Pat]

Not sure this is a jbsim problem, but:

Start Flightgear using fgrun at ksfo with c172P
fly.  normal flight.
Exit Flightgear


restart flightgear using fgrun
Change airport to Lansing Muni 
try to fly.  Plane behaves badly.  My yoke does the opposite of usual
I push in and nose raises, pull out and nose lowers
Very odd.



On Sat, 19 Jan 2013 22:48:28 +0100
Torsten Dreyer  wrote:

> Hi,
> 
> I have just synced the latest and greatest JSBSim into FlightGear.
> I flew a quick pattern with the SenecaII (the only JSBSim aircraft, I 
> have a rating for) and found no quirks.
> Please check, if everything is still working in more complex aircraft.
> 
> Greetings,
> Torsten
> 
> --
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills
> current with LearnDevNow - 3,200 step-by-step video tutorials by
> Microsoft MVPs and experts. SALE $99.99 this month only -- learn more
> at: http://p.sf.net/sfu/learnmore_122912
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel


--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Wayland, again

[Pat]

On Tue, 08 Jan 2013 08:31:23 -0800
Jack Johnson  wrote:

> Awright then, I'll find out how to make a Wayland program and then 
> supply you a prototype Wayland OSGV.
> 

Jack,

If you need someone to test anything let me know

What are you planning for a wayland build environment?

Right now I build Fg using brisa's download and compile script.   That
could be adapted for the Wayland/Weston builds right along side osg.


-Pat Callahan
 P.S. I'm about 1 nautical mile from Wayland Ma, Weston Ma is a few
 miles east.  

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Musings on FG on Linux/Windows

[Pat]

On Sun, 02 Dec 2012 14:53:03 +0100
Hans Janssen  wrote:

> On 12/02/2012 02:35 PM, Curtis Olson wrote:
> >  and as far as I know, there isn't an upper
> > limit to the number of participants in a hangout.
> 
> The limit is 10 according to this.
> https://support.google.com/plus/bin/answer.py?hl=en&answer=1216374
> 
> Hans.

ok so 10 at a time. with a waiting room on irc...


and with a fast connection for video.
Now I just need a camera my logitech headset working and we're good
to go.

-Pat







--
Keep yourself connected to Go Parallel: 
DESIGN Expert tips on starting your parallel project right.
http://goparallel.sourceforge.net/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Musings on FG on Linux/Windows

[Pat]

Does this ring any bells?

http://unprotocols.org/blog:14

--
Keep yourself connected to Go Parallel: 
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Musings on FG on Linux/Windows

[Pat]

My thanks to everybody who's ever comitted anything without getting
paid money for it.  

Thank you. 

For responding to my posts on the mailing lists.
And for talking with me on irc.
Thanks for Flightgear. 
It's a great hobby.

I appreciate it and all of you.

-Pat


--
Keep yourself connected to Go Parallel: 
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Musings on FG on Linux/Windows

[Pat]

Thorsten,

Thanks.  Your response was cleared up a lot.

I had been wondering how the personal relationships between the
flightgear project and the distributions actually worked.  I was also
wondering if the process of getting flightgear into distributions was
broken and needed fixing or not. If I understand your comments, the
process is not broken and is working as well as can be expected.

Also, If I read you right, you and perhaps others are already involved
with some distributions and don't particularly want to take over
responsibility for packaging flightgear, but will work with distro
specific flightgear package maintainers to keep the packaging process
flying level by making appropriate changes in flightgear.

What can we do to make this kind of activity more visible so folks like
me have an opportunity to help in small ways.

-Pat

> Yes, it would still be nice to have a universal build. And I guess, 
> ThorstenR (and probably others) think we're therefore doing a lousy
> job and should just spend more time on FG - like work full time to
> provide you the perfect service that you clearly all deserve (and for
> free, of course) :).
>

We would never say that.  I have about 15 minutes a day of free time
and know exactly what you mean.  (Its time for dinner and Jeopardy as
I'm writing this)

> But at times you notice live is really short. You really need to
> think about what you want to do, and on which things you really want
> to spend your precious spare time on. And do I personally want to be
> responsible for building a package that runs on *any* Linux distro in
> the universe - and to somehow take care of all their ugly tweaks? To
> be frank: no.
> 
Amen!

> The advantage of the current approach is: it distributes the work. It 
> involves people which actually know and care about their individual 
> distros - and, at least I do not need to do it all on my own. Yes, it 
> may mean there's an extra latency before a new version becomes
> available for some distros. But is it really _so_ bad, like Debian
> users apparently seeing an 8 month delay? Or that Linux users may
> need to update their OS every 2 years (well, you have to update
> anyway, since maintenance and security updates stop).

Nothing at all wrong.  Some of us just need to understand, and
you've explained it well.

>  Also, to me it
> feels like the really hard-core Linux FlightGear people, which
> _really_ care about running the very latest version (people like
> you!), even consider FG 2.8 outdated - and directly run Git instead.
> Updating weekly... ;-)


> 
> If, however, anyone feels he could do it - provide a universal 
> installation - or run a build which produces packages for every
> distro - you'll surely get my support. I'm also happy to accept merge
> requests on the OBS, if anyone can really get the cross-platform
> build to work.
> 

What's an OBS.  (Don't answer that I'll look it up ...)




Gotta run.  Biscuits are ready to come out of the oven.

-Pat

--
Keep yourself connected to Go Parallel: 
VERIFY Test and improve your parallel project with help from experts 
and peers. http://goparallel.sourceforge.net
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Musings on FG on Linux/Windows

[Pat]

For me the question is not so much how to get there, but where do we
want to go and who's going to make the effort.

>From reading this thread and others, a lot of work done on
managing the release process.  Is there still some work to do in the
area of builds for various audiences?

Which distros have flightgear and what version do they have in their
repositories?

Where did the package for Ubuntu come from?  Who built
the package? Who maintains it?  

Is there a way to manage packaging across distros?





--
Keep yourself connected to Go Parallel: 
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] download_and_compile.sh

[Pat]

I've been learning a lot about Linux development by reading the
download_and_compile.sh.  I have a few ideas for enhancements to the
script.

Is anyone keeping a list of requested enhancements to the script?

Is this list the right place for discussion of the script and changes
to it?

-Pat

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel