User:Callahanp/Building and Running Flightgear basics Building and Running Flightgear - The Basics

From FlightGear wiki
< User:Callahanp
Revision as of 19:00, 25 February 2020 by Callahanp (talk | contribs) (Initial Overview - Needs specific examples)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
WIP.png Work in progress
This article or section will be worked on in the upcoming hours or days.
See history for the latest developments.

Building and Running a software program uses a few basic concepts that should be familiar to most readers: Data Transformations, Processing Stages, Configuration Data, File Paths, File Names and File Types. There are just a few types of Data Transformations needed, done in stages because the output of one transformation will be used in later transformations. Configuration data controls the specifics of the process including the order of processing, which programs are used at each stage, where the inputs to those programs are to be found, what kind of output is desired and where the outputs should be placed.

Understanding an existing build process, or modifying one to suit a new desired output is mostly an effort to understand the individual stages of processing, the configuration entries that affect each stage individually and the results at subsequent stages. Running the program can be thought of as just another stage in the process.

So what are these stages:

  • Script, Command or IDE Invocation of the Build
  • Initial Build Configuration Processing
  • Pre-Compiliation Processing
  • Compilation
  • Linking
  • Installing
  • Running the Program

A specific configuration for a build is just input data. The data can be sourced from System, User or Process Variables, Command Line Arguments, entries in configuration files or in default values contained within the individual programs that are run during the build. Input configuration data can include items describing where to get specific files, where to look for files of a particular type, which program to use in a given stage of processing. It may specify the type of program to produce, for example, a debug or a release build. It might specify the type of processor the built program can run on, such as X64 or X32. It might specify that dynamic or static linking will be used.

All of that is pretty general. What you want in an actual build process is a fairly complete set of files that can be processed in a variety of environments to produce desired targets without too much individual configuration for each individual target. You'll want a process that produces configuration files that work in ways familiar to users of the local toolchain, whether it's based on Visual Studio, Visual Studio Code, vcpkg, Eclipse, NetBeans or the plain old command line in Windows, Mac or Linux. You'll want it to be capable of supporting a variety of compilers, gcc, clang, msvc etc.

Now we've progressed from the world of general statements about building to specific real world scenarios to build target software that works as intended, whether its a full public release intended for end users on three OS Platforms, or a running debug build under a specific IDE on just one of them.

So let's take a closer look at some. We'll start with the vcpkg builds for specific packages used by OpenSceneGraph, Simgear and/or Flightgear. We'll focus on 5 packages, one of which seems to cause no issues and four of which seem to be problematic in some way for debug builds.