1,885
edits
Changes
Created page with 'Category:SBR600 LabsCategory:DPI908 = Purpose = * To become familiar with the build process. * To create a foundation for later labs. = Building from Source Code = Sou…'
[[Category:SBR600 Labs]][[Category:DPI908]]
= Purpose =
* To become familiar with the build process.
* To create a foundation for later labs.
= Building from Source Code =
Source code is the human-readable code used to write software. It usually consists of text files, and may include related data (graphics, sample data, fonts, and so forth).
Source code may be:
# Executed by an interpreter (such as bash), which reads the text of the source code and performs the relevant operations.
# Compiled into ''machine code'', which can then be directly executed by a computer (either directly by the CPU, or by a virtual machine). Files containing machine code are called ''binaries'', ''executables'', or ''bytecode''.
The process of preparing software for use is called ''building''. Note that this may include compiling the software, but it may involve other operations, such as compiling fonts, processing data (such as game levels), converting file formats, and so forth.
= Preparing to Build =
Before you attempt to build on a system, you will need to install the development tools (compilers, linkers, and so forth) and development libraries needed for that particular package. You can install a foundation set of development tools on a Fedora system with this command:
yum groupinstall "Development Tools" "Development Libraries"
You may need to install additional tools or libraries to meet the needs of the package you are building. Refer to the documentation for that package for specific details. ''Do not'' install tools or libraries from source code -- install them using the <code>yum</code> command.
= Timing Commands =
Bash provides the built-in ''time'' command to determine how long a command takes to execute. To use it, just type <code>time</code> in front of the other command:
$ '''time make'''
real 1m39.716s
user 1m20.144s
sys 0m15.076s
Note that the output shows three different times:
* real - the actual time taken to run the command
* user - the amount of time the CPU was running the command
* sys - the amount of time the CPU was performing kernel operations which were initiated by this command
In the example above, the ''make'' command took 1 minute 39.716 seconds to execute, of which 1 minute 20.144 seconds was spent executing the software and 15.076 seconds was spent running kernel code. During the remaining 4.496 seconds, ''make'' was not being executed -- either because the CPU was busy running other processes, or because ''make'' was waiting for input/output (I/O) -- for example, waiting for data to be read from disk.
= Steps =
# Select two packages from the [http://www.gnu.org/software/software.html#allgnupkgs GNU software collection] (these packages were chosen because they are written to high standards and generally build with few problems).
# Download the code.
# Build each package on your Fedora system, noting each command used and the length of time taken.
The steps required to build a package vary, but generally include some combination of these steps:
# Unpack the tarball (<code>tar xvzf ...</code>) or zip file (<code>unzip ...</code>)
# Change to the directory containing the unpacked files. At this point, it's a good idea to read the build instructions, which are typically in a file named <code>INSTALL</code> or <code>README</code>.
# Run a script that configures the build for our particular system (typically <code>./configure</code>)
# Run a script to build the software (typically <code>make</code>)
# At this point, the software would usually be installed (<code>make install</code>)-- avoid doing this to avoid overwriting files on your system.
# Test the software by running it (if it can be run without installation) - you will have to find the binary.
If something goes wrong, read the error messages carefully to see if a tool or library needs to be installed.
{{Admon/tip|Hard Packages to Build|Don't get stuck on a package which is particularly hard to build -- feel free to skip that package and select another one [http://www.gnu.org/software/software.html#allgnupkgs from the list].}}
= Deliverable =
{{Admon/tip|Write well!|Even when writing a technical post, you can make it interesting to read. Assume that the reader has stumbled across your post and has no context for what she is reading, so include links to relevant material and ensure that the post makes sense when read on its own. Include short snippets of command output when they are relevant to your writing, but avoid straight cut-and-paste of large amounts of command output (which will put your readers to sleep!). Include screenshots of GUI applications where appropriate, but do not include screenshots of text -- insert the text into your post instead. Check your blog post for grammar, spelling, readability, and accuracy before posting.}}
Create a blog post describing your experience. Include:
* Notes on what you did, and what worked and didn't work.
* How long the process took.
* The results, including a link to the software you built.
Consider including relevant command output from the build process and/or screenshots of the freshly-built software.
= Purpose =
* To become familiar with the build process.
* To create a foundation for later labs.
= Building from Source Code =
Source code is the human-readable code used to write software. It usually consists of text files, and may include related data (graphics, sample data, fonts, and so forth).
Source code may be:
# Executed by an interpreter (such as bash), which reads the text of the source code and performs the relevant operations.
# Compiled into ''machine code'', which can then be directly executed by a computer (either directly by the CPU, or by a virtual machine). Files containing machine code are called ''binaries'', ''executables'', or ''bytecode''.
The process of preparing software for use is called ''building''. Note that this may include compiling the software, but it may involve other operations, such as compiling fonts, processing data (such as game levels), converting file formats, and so forth.
= Preparing to Build =
Before you attempt to build on a system, you will need to install the development tools (compilers, linkers, and so forth) and development libraries needed for that particular package. You can install a foundation set of development tools on a Fedora system with this command:
yum groupinstall "Development Tools" "Development Libraries"
You may need to install additional tools or libraries to meet the needs of the package you are building. Refer to the documentation for that package for specific details. ''Do not'' install tools or libraries from source code -- install them using the <code>yum</code> command.
= Timing Commands =
Bash provides the built-in ''time'' command to determine how long a command takes to execute. To use it, just type <code>time</code> in front of the other command:
$ '''time make'''
real 1m39.716s
user 1m20.144s
sys 0m15.076s
Note that the output shows three different times:
* real - the actual time taken to run the command
* user - the amount of time the CPU was running the command
* sys - the amount of time the CPU was performing kernel operations which were initiated by this command
In the example above, the ''make'' command took 1 minute 39.716 seconds to execute, of which 1 minute 20.144 seconds was spent executing the software and 15.076 seconds was spent running kernel code. During the remaining 4.496 seconds, ''make'' was not being executed -- either because the CPU was busy running other processes, or because ''make'' was waiting for input/output (I/O) -- for example, waiting for data to be read from disk.
= Steps =
# Select two packages from the [http://www.gnu.org/software/software.html#allgnupkgs GNU software collection] (these packages were chosen because they are written to high standards and generally build with few problems).
# Download the code.
# Build each package on your Fedora system, noting each command used and the length of time taken.
The steps required to build a package vary, but generally include some combination of these steps:
# Unpack the tarball (<code>tar xvzf ...</code>) or zip file (<code>unzip ...</code>)
# Change to the directory containing the unpacked files. At this point, it's a good idea to read the build instructions, which are typically in a file named <code>INSTALL</code> or <code>README</code>.
# Run a script that configures the build for our particular system (typically <code>./configure</code>)
# Run a script to build the software (typically <code>make</code>)
# At this point, the software would usually be installed (<code>make install</code>)-- avoid doing this to avoid overwriting files on your system.
# Test the software by running it (if it can be run without installation) - you will have to find the binary.
If something goes wrong, read the error messages carefully to see if a tool or library needs to be installed.
{{Admon/tip|Hard Packages to Build|Don't get stuck on a package which is particularly hard to build -- feel free to skip that package and select another one [http://www.gnu.org/software/software.html#allgnupkgs from the list].}}
= Deliverable =
{{Admon/tip|Write well!|Even when writing a technical post, you can make it interesting to read. Assume that the reader has stumbled across your post and has no context for what she is reading, so include links to relevant material and ensure that the post makes sense when read on its own. Include short snippets of command output when they are relevant to your writing, but avoid straight cut-and-paste of large amounts of command output (which will put your readers to sleep!). Include screenshots of GUI applications where appropriate, but do not include screenshots of text -- insert the text into your post instead. Check your blog post for grammar, spelling, readability, and accuracy before posting.}}
Create a blog post describing your experience. Include:
* Notes on what you did, and what worked and didn't work.
* How long the process took.
* The results, including a link to the software you built.
Consider including relevant command output from the build process and/or screenshots of the freshly-built software.