Specifications

files (see below for details). You may specify which sub-steps of the build step are to be performed.
The formal syntax for the usage of build.sh is as follows:
bash$ ./build.sh [-a <arch>] [-n <name>] [-p <prefix>] [-r <result>] \
[-w <work>] <step_name> [<sub_step_number>]
-a <arch> target architecture: "ppc", "ppc64", "arm" or "mips", defaults to "ppc".
-n <build_name> an identification string for the build. It is used as a name for some directories
created during the build. You may use for example the current date as the build
name.
-p <prefix> is the name of the directory that contains the build environment. Refer to build
overview above for description of the build environment.
-r <result> is the name of the directory where the resulting RPMs and SRPMs created on this
step will be placed.
-w <work> is the name of the directory where the build is performed.
<stepname> is the name of the build step that is to be performed. Refer to the list of the build
procedure steps above.
<sub_step_number> is an optional parameter which identifies sub-steps of the step which are to be
performed. This is useful when you want to re-build only some specific packages.
The numbers are defined in the cpkgs.lst and tpkgs.lst files discussed below. You
can specify a range of numbers here. For instance, "2 5" means do steps from 2 to
5, while simply "2" means do all steps starting at 2.
Please note that you must never use build.sh to build the ELDK from scratch. For build.sh to work
correctly, the script must be invoked from the build environment after a successful build using the
ELDK_BUILD script. A possible scenario of build.sh usage is such that you have a build environment
with results of a build performed using the ELDK_BUILD script and want to re-build certain ELDT and target
packages, for instance, because you have updated sources of a package or added a new package to the build.
When building the target packages (during the trg buildstep), build.sh examines the contents of the
TARGET_CPU_FAMILY_LIST environment variable, which may contain a list indicating which target CPU
variants the packages must be built for. Possible CPU variants are arm. For example, the command below
rebuilds the target RPM listed in the tpckgs.lst file under the number of 47 (see section 3.10.4. Format of the
cpkgs.lst and tpkgs.lst Files for description of the tpckgs.lst and cpkgs.lst files), for the arm CPU:
bash$ TARGET_CPU_FAMILY_LIST="arm" \
> /opt/eldk/build.sh -a arm \
> -n 2007-01-21 \
> -p /opt/eldk/build/arm-2007-01-21 \
> -r /opt/eldk/build/arm-2007-01-21/results \
> -w /opt/eldk/build/arm-2007-01-21/work \
> trg 47 47
Note: If you are going to invoke build.sh to re-build a package that has already been built in the build
environment by the ELDK_BUILD script, then you must first manually uninstall the package from ELDK
installation created by the build procedure under the work directory of the build environment.
Note: It is recommended that you use the build.sh script only at the final stage of adding/updating a
package to the ELDK. For debugging purposes, it is much more convenient and efficient to build both ELDT
and target packages using a working ELDK installation, as described in the sections 3.8.2. Rebuilding Target
Packages and 3.8.3. Rebuilding ELDT Packages above.
3.10.3. build.sh Usage 29