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

Jump to navigation Jump to search
no edit summary
No edit summary
Line 1: Line 1:
== Pat's Proposals ==


Pat is proposing a series of patches to the script and a maintenance tool with the following goals:
== Implementation Plan ==


# provide support for creating patches to download_and_compile.sh in a separate external script)
# Script and cmake debugging features has been included in 1.9-10 as options w, x and v
# Annotate the sections of the script to document its overall flow and provide a basis for script feature discussions
# Create a team clone on [http://www.gitorious/org/fg/fgmeta specifically for work on this script.
# Add options to the script to support debugging:
# Expanded help and labels for script sections is implemented in 1.9-10 and 1.9-11
# Clarify the use of and current position in the hierarchy of directories
# Support for additional releases and tags is undergoing testingIt will be relaased as 1.9.12
# Allow builds for all branches and recent versions
# Instructions to allow the script to use a single copy of fgdata are working but not fully tested. This needs to be implemented in the script
# Keep the build and install folders and the log files separate for each branch, version and set of options affecting what is built
# Ensure that only one download of fgdata, plib and osg is done and then used for all buildsThis will reduce network load on gitorious.org and speed up building
# Label log files by changing their file names to indicate what was built and when.


Details at the end of this page for those interested in reading through a Lot of ideas.
=== Proposals ===
#  Change the way directories are handled has been discussed, this has been prototyped and will be implemented in a future release
#  Change the way the log file is produced.
#  Add support for both stable and latest osg.
#  build while downloading
#  download fgdata as a restartable bundle
#  download all scenery (or maybe specific regions?)
#  Add version of flightgear to be built at the top of the compiliation log
#  add version of flightgear being built to the window label
#  SUSE, Redhat/yum & CENTOS support
#  network setup tests for fgcom, multiplayer and terragear
#  torrents
 
== makeffile and cmake idea (needs discussion) ==
 
# use of makefile or cmake as a basis for or as part of the script.  
Advantages:
 
# Cross Platform.
# fits with general direction things seem to be moving in.
 
Disadvantages:
 
# Cmake and makefiles can be difficult for the un-initiated.
 
Opinion:
 
# This is a great idea, Should it be a separate alternative script? [[User:Callahanp|Callahanp]] 11:34, 31 May 2013 (UTC)


== Clear description of what is being built in the log file ==
== Clear description of what is being built in the log file ==
Line 34: Line 57:
for better use of bandwidth, it would make sense to also download while compiling (i.e. when building plib and osg, download simgear, when building simgear, download flightgear - and the fgdata checkout/update can also be initiated early). It might make sense to turn the shell script into a conventional makefile that supports dependency resolution and parallel steps, so that network-bound tasks like downloading (fgdata!) can be interleaved with the build process. The run_FOO scripts could then become conventional make targets.
for better use of bandwidth, it would make sense to also download while compiling (i.e. when building plib and osg, download simgear, when building simgear, download flightgear - and the fgdata checkout/update can also be initiated early). It might make sense to turn the shell script into a conventional makefile that supports dependency resolution and parallel steps, so that network-bound tasks like downloading (fgdata!) can be interleaved with the build process. The run_FOO scripts could then become conventional make targets.


 
== Details of Implementation Plan Items ==
 
== Details of Pat's Proposals ==
 
I'm trying to present this as I would a specification, so there is a lot of detail here. Sorry about that!
 
=== provide support for creating patches to download_and_compile.sh ===
 
A separate new script, patchkit has been created.  It supports editing a new change to the script, creating a patch based on the changes, testing the change and delivering it to Francesco for consideration.
 
===Annotate the sections of the script to document its overall flow and more importantly to support script feature discussions ===
Clearly label the sections of the script as sections:
List the sections in script help
 
# Script Section: Option Initialization
# Script Section: Option Interpretation
# Script Section: Build Argument Interpretation
# Script Section: Set Source Archive Version Variables
# Script Section: Display Script Help
# Script Section: Helpful Messages
# Script Section: Display Options Chosen
# Script Section: Determine Linux Distribution
# Script Section: Install Prerequisite Packages
# Script Section: Create Required Directories
# Script Section: Build Components
## Script Section: PLIB
## Script Section: OpenSceneGraph
## Script Section: openrti
## Script Section: simgear
## Script Section: fgfs and fgdata
## Script Section: fgo!
## Script Section: fgx
## Script Section: fgrun
## Script Section: fgcom
## Script Section: fgcomgui
## Script Section: atlas
 
Status: Submitted to Francesco for consideration
 
=== Add debugging options ===
Add w, x and v options to the script:
* w - causes cmake to run makefiles in verbose mode
* x - set x in bash (for debugging)
* v - set v in bash (for script debugging)
 
Status: Part of 1.9-10
 


=== Clarify the use of and current position in the hierarchy of directories ===
=== Clarify the use of and current position in the hierarchy of directories ===
Line 101: Line 78:
I'm proposing that we change this by adding to the  Script Section: Create Required Directories.
I'm proposing that we change this by adding to the  Script Section: Create Required Directories.


This section currently just ensures that there is an install directory.  I'd expand this to define variable names for each directory in the list above and use the variable names for directory navigation in the sections that build and install the components.  It also forms the basis for the next several features...
This section currently just ensures that there is an install directory.  I'd expand this to define variable names for each directory in the list above and use the variable names for directory navigation in the sections that build and install the components.   


=== Ensure that only one download of fgdata, plib and osg is done and then used for all builds.  ===  
=== Ensure that only one download of fgdata, plib and osg is done and then used for all builds.  ===  


This will reduce network load on gitorious.org and speed up building.  The same will apply for other components that do not need multiple versions to support development and specific versions.
Provide a standard place to put one or more versions of fgdata, and a single place for plib and osg etc.  This would be immplemented using symbolic links as described in [[Avoiding Multiple Downloads of fgdata]]
 
Using the scheme above for variables defining specific directories, provide a standard place to put one or more versions of fgdata, and a single place for plib and osg etc.  This would be very similar to the way the script handles them today. 


=== Allow builds for all branches and recent versions ===
=== Allow builds for all branches and recent versions ===


Currently the script can build next, or a single released version.  I'd expand this to allow building next, master, maint, the current release and a previous releaseThe next item allows us to do this easily.
Currently the script can build next, or a single released version.  Changes to allow this via the B (Branch) and R (revision) options are being tested for script version 1.9.12.   


=== Keep the build and install folders and the log files separate ===
=== Keep the build and install folders and the log files separate ===
Line 124: Line 99:


This is straightforward enough, just delay logging until all parameters are processed.
This is straightforward enough, just delay logging until all parameters are processed.
But there's an additional thing that might be considered.  After the log file is determined, start a sub-process with output to the log file, pass it the same parameters as were passed in,  then exit  This would allow us to remove constructs like |tee $LOGFile and >> $LOGFILE.  When x and v are chosen, it provides a log of all bash steps. (nice)
But there's an additional thing that might be considered.  After the log file is determined, start a sub-process with output to the log file, pass it the same parameters as were passed in,  then exit  This would allow us to remove constructs like |tee $LOGFile and >> $LOGFILE.  When x and v are chosen, it provides a log of all bash steps. (nice for debugging the script)
 
== Pat's Implementation Plan ==
 
# Patch for debugging features has been included in 1.9-10
# Patch to allow the script to use a single copy of fgdata is fully working
# Patch to expand help and label script sections is fully working
# Patch to change the way directories are handled is proposed, this is partially working
# Patch to support additional types of builds is proposed, this is partially working
# Patch to change the way the log file is produced is proposed
982

edits

Navigation menu