Talk:Scripted Compilation on Linux Debian/Ubuntu: Difference between revisions

Jump to navigation Jump to search
m
no edit summary
mNo edit summary
Line 53: Line 53:
## the build should produce a debug version
## the build should produce a debug version
##  set flags for debug, build options for use of openrti
##  set flags for debug, build options for use of openrti
#
== Future Script Versions ==


== Future Script Versions ==
== Future Script Versions ==
Line 68: Line 65:
* where to put sources, build and install
* where to put sources, build and install
* which version of fgdata to use
* which version of fgdata to use
* special configuration options
* additional configuration options
* get original sources Y/N
* get original sources Y/N
* update sources Y/N
* update sources Y/N
Line 90: Line 87:
* placing source directories at a higher level of the directory hierarchy, while building and installing in a lower level
* placing source directories at a higher level of the directory hierarchy, while building and installing in a lower level
* keeping versions of source, build and install directories specific to a particular distribution in a way that supports preparation of new versions for the distribution.
* keeping versions of source, build and install directories specific to a particular distribution in a way that supports preparation of new versions for the distribution.
Let CMake drive the process


=== Proposed features -- New features of the script that have yet to be implemented ===
=== Proposed features -- New features of the script that have yet to be implemented ===
Line 115: Line 114:
* how much of the scripts logic can we delegate to cmake?
* how much of the scripts logic can we delegate to cmake?


=== Proposed features -- New features of the script that have yet to be implemented ===
* 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
* No more multiple download and builds of plib and osg. You download and build plib-1.8.5 and osg-3.0.1 once. Their sources are kept in a separate directory.
* A single copy of flightgear, simgear and openrti sources that can be used to build whatever versions are needed, one at a time
* Support for additional versions of osg such as 3.1.9
*  Add support for both stable and latest osg.
*  build while downloading
*  download fgdata as a restartable bundle (FGDATA is being broken up so this may be less of an issue from 3.0 forward.
*  download all scenery (or maybe specific regions?)
*  SUSE, Redhat/yum & CENTOS support
*  Distribution builds
*  network setup tests for fgcom, multiplayer and terragear
* torrents
* When updating the sources, its possible to automatically detect if a reconfiguration is needed or not.
* You might want to control which components are rebuilt and which are simply recompiled and re-linked
* You might be in the process of updating a file in one of the components.  How would the build need to change to avoid overwriting your change.
* We currently use the main flightgear git archives for sources.  Its possible to use personal or team clones for one or more components instead?
* Do we need better reporting of the results of the build?
* what can we do with cmake to reduce the bash code used to make decisions about what steps need to be done?
* how much of the scripts logic can we delegate to cmake?


==  git usage ==
==  git usage ==
982

edits

Navigation menu