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 22:27, 19 March 2013
, 19 March 2013Pat has proposed a raft of changes to download_and_compile.sh
(Pat has proposed a raft of changes to download_and_compile.sh) |
|||
| 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: | |||
# provide support for creating patches to download_and_compile.sh in a separate external script) | |||
# Annotate the sections of the script to document its overall flow and provide a basis for script feature discussions | |||
# Add options to the script to support debugging: | |||
# Clarify the use of and current position in the hierarchy of directories | |||
# Allow builds for all branches and recent versions | |||
# 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 builds. This 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. | |||
== Clear description of what is being built in the log file == | |||
When running the download_and_compile script, it would be nice if the version of FlightGear being installed is displayed early on (e.g. so that it appears at the top of the compilation_log.txt file). Is it easy to add this to the script? Or is there another obvious way to find the version? In the download_and_compile script the last stable revision is stated. But is this line always correct? | When running the download_and_compile script, it would be nice if the version of FlightGear being installed is displayed early on (e.g. so that it appears at the top of the compilation_log.txt file). Is it easy to add this to the script? Or is there another obvious way to find the version? In the download_and_compile script the last stable revision is stated. But is this line always correct? | ||
| Line 16: | Line 33: | ||
== Building while downloading == | == Building while downloading == | ||
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 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: Submitted to Francesco for consideration | |||
=== Clarify the use of and current position in the hierarchy of directories === | |||
As part of its work, the script must reposition itself in directories and refer to files in other directories. It does this at numerous points when building each of the 12 flightgear components. | |||
The common method is to position to $CBD, the current build directory and then move to sub folders as needed, usually on level at a time. The script use cd .. to move back out of the sub directories. | |||
Relevant directories include: | |||
* $CBD - The "Current Build Directory" | |||
* a directory one level above the git top level for a component | |||
* the directory contaiing the top level of the git archive | |||
* the top level of sources for the component (usually the same as the git archive | |||
* a build directory for all components | |||
* an install directory for all components | |||
* a build directory for a specific component (12 of them) | |||
* an install directory for a specific component (12 of them) | |||
* a directory for fgdata | |||
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... | |||
=== 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. | |||
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 === | |||
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 release. The next item allows us to do this easily. | |||
=== Keep the build and install folders and the log files separate === | |||
For each branch, version and set of options affecting what is built keep a separate set of build and install folders. | |||
Since the script is now capable of building several branches and versions, each with a selectable set of options that affect the build, it makes sense to be able to keep these various builds for usage and testing. | |||
In the scheme for assigning variables to represent all directories, the build and install top levels can be changed from just build and install to names that describe specific builds and installs. For example: build_master_ei to hold the build directories for openrti, simgear and fgfs when building from the master branch with options e & i. | |||
=== Label log files by changing their file names to indicate what was built and when. === | |||
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) | |||
== Pat's Implementation Plan == | |||
1. Patch for debugging features has been submitted to Francesco. | |||
2. Patch to allow the script to use a single copy of fgdata is being prepared for testing | |||
3. Patch to expand help and label script sections is being prepared for testing | |||
4. Patch to change the way directories are handled is proposed | |||
5. Patch to support additional types of builds is proposed | |||
6. Patch to change the way the log file is produced is proposed | |||