tsrpm Hints
Hints are a powerful mechanism available to the tsrpm user for modifying the behavior of a command executed in the tsrpm environment. Hint files are stored alongside the .spec files in the package source tree. Hints allow you to modify the behavior of an rpmbuild command and everything that runs under its control without having to change the .spec file, the Makefiles, or the autoconf template files. This significantly improves the ease of maintenance of packages and allows the developer to move easily across package revisions without having to patch the package code and migrate patches across revisions.
Passing Environment Variables to tsrpm
Environment variables are passed to tsrpm by putting them in a .tshint file. A .tshint file is a shell script that you create, which is sourced by tsrpm at various points.
The .tshint file for a given package should be created in the same directory as the .spec file for the package and have the same base name as the .spec file. For example, if you have a package named package, whose sources are located in the /rpm-sources/package-1.2.3-1 directory and whose .spec file is, therefore, /rpm-sources/package-1.2.3-1/package.spec, you would create a .tshint file named rpm-sources/package-1.2.3-1/package.tshint that identifies the environment variable that you want to create and the value that you want it to have, such as:
export LINUX_SOURCE=/usr/src/linux
Usually, it is better to specify exactly when you want the export to happen, so as to minimize impact on other programs. To do this, you can conditionalize the contents of this file by doing something like the following:
if ispgm make; then export LINUX_SOURCE=/usr/src/linux fi
In this conditionalized section, the environment variable LINUX_SOURCE would be set to /usr/src/linux only when running the make program.
Creating New Cross-Tools
As you develop your application-specific embedded Linux platform, you might need to create new cross-tools that are specific to your development needs. Build cross-tools with the following command:
tsrpm --cross-tool --build zlib
Different packages vary in their ability to be built correctly as a cross-tools, especially packages that produce executables. If a package can be built correctly as a cross-tool, it will correctly build binaries that run on the host, rather than on the target. For such packages, set the following hint in the package hints file:
if ispgm perpackage; then set_cross_tool_ok fi
Without this hint, tsrpm assumes that this package is a library, which might not be properly generated using normal cross-compile syntax. In this case, it will first build the library for the target, and then make changes so that only the library and header file components are installed.
Excluding Package Content
Because you will often want to exclude package content for only one or a few builds, tsrpm allows you to do this on the command line. The following example excludes adjtime from the ntp package:
tsrpm --exclude=/usr/sbin/adjtime --repackage=targetipkg ntp
Such exclusions can also be specified as hints. The previous command is incorporated here in the ntp.tshint file:
if ispgm rpm_repackage; then add_exclusion /usr/sbin/adjtime fi
Modifying Package Dependencies
Packages built with rpm might have dependencies on other packages that are not available on the target. This situation can create difficulties, especially if a run-time package management system is to be used on the target.
You can modify package dependencies during repackaging. For example, if a package has a dependency on bash, and the target RFS supports only the busybox shell, the dependency can be modified using a hint file fragment, as shown in the following example:
if ispgm rpm_repackage; then
modify_dependency bash busybox
fi
Changing Command Arguments During a Build
During the process of building a package for a particular target of interest, there are many reasons why the build commands need to be tweaked. A typical reason is broken Makefiles. Another reason is the need to customize commands to make them appropriate for a particular target, such as using gcc to execute the link command instead of using ld, or adjusting optimization levels to be more or less aggressive.
Modifying the make Invocation
If you want to pass a parameter to make while building a package (for example, foo-1.2.3-1), add the following script fragment to foo.tshint and place this hints file in the same directory as foo.spec:
if ispgm make; then export TSRPM_MAKE_FOO=/bin/foo fi
This will add the line MAKE_FOO=/bin/foo to the make command line.
Modifying Command Line Arguments
You can also add, remove, or modify arbitrary arguments to other programs with a construction similar to the following one:
if ispgm make; then
# Set the value of LD to be the same as the value of CC on the make command line
export TSRPM_MAKE_LD=$TSRPM_MAKE_CC
elif ispgm target-gcc; then
appendargs -DUSING_BLAH=1
elif ispgm configure && istarget mips; then
#Massage the configure script without changing the spec file
rmargs --with-gtk
modifyargs -e 's/--with-nptl/--with-linux-threads/'
prependargs --with-mips-magic
fi
Modifying Package Optimization Levels
During the development cycle, there is often a need to experiment with different levels of compiler optimizations for a package. For instance, there might be a need to drop optimization altogether in debug builds for a package, or to optimize a package for size. tsrpm supports two mechanisms for making such changes.
One approach is to change the value of the TSRPM_OPTFLAGS variable from its default setting, as shown in the following example:
if ispgm perpackage; then export 'TSRPM_OPTFLAGS=-O1 -g' fi
The other approach is to modify the gcc arguments, as shown in the following example:
if ispgm target-gcc; then
modifyargs -e 's/-O2/-O0/'
fi
Using modifyargs is the safer of these two approaches since it guarantees that the optimization will be changed; whereas, if the package is not correctly designed, TSRPM_OPTFLAGS might not get used.
However, it is still preferable to use TSRPM_OPTFLAGS whenever possible because when it does work, you will see the optimization in tsrpm's output every time. The optimization is not evident in the output with modifyargs because it takes place after the command has already been echoed to the log. If you wish to verify that modifyargs actually changed the arguments as desired, run the tsrpm build after touching the runnext.verbose file in the working directory. This will echo the modified command to the log.
