982
edits
Talk:Scripted Compilation on Linux Debian/Ubuntu: Difference between revisions
Jump to navigation
Jump to search
Talk:Scripted Compilation on Linux Debian/Ubuntu (view source)
Revision as of 00:58, 29 September 2013
, 29 September 2013→Alternative Coding approaches to implement the features -- Ways to structure the script so it can be easily understood and maintained
| Line 54: | Line 54: | ||
## 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 78: | Line 80: | ||
A different approach would be to re-spawn the script with 2>&1 tee | A different approach would be to re-spawn the script with 2>&1 tee | ||
Another would be to have an additional log files with timestamped log entries indicating what is to be done, what has completed successfully and what exactly failed. | Another would be to have an additional log files with timestamped log entries indicating what is to be done, what has completed successfully and what exactly failed. | ||
Preventing multiple downloads of fgdata, or other sources such as OSG | |||
Currently the script uses a single way to structure directories for sources, data, building and installing. In order to support the proposed features that would prevent multiple downloading of sources and data, a different structure may make things easier. | |||
For example, | |||
* separate directories for each version of fgdata, with clones of the main git archive in each one, set to the branch needed for a particular version of flightgear | |||
* separate directories for different source versions of a pre-requisite development package such as OSG or Boost | |||
* 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. | |||
=== 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. | |||
* support for personal and team clones of components to be built | |||
* installing components in a system location | |||
* 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? | |||
=== 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 === | ||