tconf(1) BSD General Commands Manual tconf(1)
NAME
tconf -- TargetConfig command line tool
SYNOPSIS
tconf --product
tconf --archs
tconf --cflags
tconf --cppflags
tconf --cxxflags
tconf --ldflags
tconf --cc
tconf --cpp
tconf --cxx
tconf --ld
tconf [-q] [--altfeaturesdir directory] --test variable
tconf --export-header[=pathname.h]
DESCRIPTION
The tconf utility allows Makefiles to obtain static configuration information about the target build platform. This is useful for specifying
compile-time settings when cross-building (where runtime tests are not possible).
The tconf obtains its configuration information from a property list contained in the SDK specified by the SDKROOT environment variable. If
SDKROOT is not set, then tconf will attempt to read a property list on the build host as specified by the RC_TARGET_CONFIG environment vari-
able in the directory /usr/share/TargetConfigs. If the RC_TARGET_CONFIG environment variable is not set, the value "Default" is used.
The main options to tconf are usually used one at a time per call. However, more than one option in the first three groups may be used on
the same call to tconf (except as note below for the third group's -q option). Each line of output will be prefixed with the option name and
an equal sign, to distinquish that output from others. Multiple occurrences of any of the options in the first two groups are suppressed;
only one output line is printed per option.
The --product flag prints the target product name (i.e. "MacOSX") to standard output.
The --archs flag prints the target architectures to standard output. When the RC_ARCHS environment variable is set, its value is used. Oth-
erwise, the set of architectures defined in the TargetConfig property list is printed.
In the second group of tconf calls, the corresponding compiler settings defined in the "TargetConfig" section of the property list is
printed.
In the third group, the --test option is used to inquire about two types of data. The first type of data is the target variables in the
property list. Setting the variable argument to the name of a target conditional variable (from the "TargetConditional" section of the prop-
erty list) will print "YES" to standard output if the value of the variable is true, otherwise "NO" is printed. Target conditional variables
include:
TARGET_OS_MAC
TARGET_OS_WIN32
TARGET_OS_UNIX
TARGET_OS_EMBEDDED
TARGET_RT_MAC_CFM
TARGET_RT_MAC_MACHO
The values of the target variables defined in the "TargetArchitectures" section of the property list can also be displayed by setting
variable to arch:name, where arch is a particular architecture, and name is the name of the target architecture variable (which all begin
with the TARGET_ prefix). If variable is only set to a target architecture variable name, those architecture(s) specified in the RC_ARCHS
environment variable are used, with a true value being returned if any of the possibly multiple architectures has that variable set to true.
The other type of data that --test can display is the availability of software features, including frameworks, libraries and header files.
The variable argument is set to type:name, where type is the type of feature, and name is the name of a particular one of that type. For
example, framework:Carbon would return "YES" if the Carbon framework is available, while library:pam would return "YES" if the pam library
(libpam) is available.
If the property list contains a "Features" section, that section is used exclusively to determine feature availability. If a type:name pair
is not found in the "Features" section, "NO" is returned, independent of whether that feature is really available.
However, if no "Features" section exists in the property list, one of several feature scripts are called to dynamically determine if the
type:name feature is available. These scripts takes into account the RC_CFLAGS, RC_TARGET_CONFIG and SDKROOT environment variables, matching
up architectures that are specified in the property list with files in the SDKROOT, or defaulting architectures not in the property list to
the standard system root.
Note: When running in the XBS environment (either via buildit or running on an XBS builder), if there is no "Features" section in the
property list, all feature queries are automatically recorded into a property list in the SYMROOT, named
.TargetConfigTestRecord.plist. This property list will eventually be collected and used to build the "Features" section of the
corresponding property list.
This is also an (empty) lock file named .TargetConfigTestRecord.lock. Using an algorithm based on link count, this lock file
works even on buggy NFS file servers. However, if tconf should crash while the file is locked, an additional (linked) file
named .TargetConfigTestRecord.lock.XXXX.XXXXXXXX.XXXX (where the X 's are a series of numbers and letters unique to each
process) will remain, causing subsequent tconf to time out waiting for the lock.
The --altfeaturesdir specifies a user-defined set of alternate scripts to run, falling back to the system-supplied ones. This should only be
used temporarily, until the /usr/share/TargetConfigs/feature_scripts directory is updated to include all scripts. This directory is never
used if the "Features" section exists in the property list.
The -q option suppresses the standard output, and instead, sets the exit status of tconf, zero for "YES" and non-zero for "NO". Because of
the single output, only one option per call is allowed with this flag. Also note that there is no way to distinquish "NO" from an error
occurring in tconf, which both return a non-zero exit status.
The last group of tconf calls is used to produce header file output, and is generally used one per call (though this is not enforced). The
--export-header option writes a C header file containing the values from the "TargetConditions", "TargetArchitectures" and "Features" section
of the property list. By default, the header file is written to the standard output, but the output can be written to a specified file by
suffixing the option with an equal sign and the path to the file (no spaces).
When there is no "Features" section in the property list and the tconf is being run in the XBS environment (as mentioned above), the previ-
ously recorded --test feature queries (also mentioned above, in the Note section), will be used. In this case, it is suggested that all
--test feature queries be evaluated first (and the results saved) before --export-header is called.
EXAMPLE USAGE IN MAKEFILES
Embedded = $(shell tconf --test TARGET_OS_EMBEDDED)
CFILES = main.c
ifeq ($(Embedded),YES)
CFILES += embedded.c
endif
CARBONAVAILABLE = $(shell tconf --test feature:Carbon)
Extra_Configure_Flags = ...
ifeq ($(CARBONAVAILABLE),YES)
Extra_Configure_Flags += --enable-toolbox-glue
else
Extra_Configure_Flags += --disable-toolbox-glue
endif
main.o: features.h
features.h:
tconf --export-header=$@
FILES
/usr/share/TargetConfigs/Default.plist
/usr/share/TargetConfigs/feature_scripts
/usr/include/TargetConfig.h
${SYMROOT}/.TargetConfigTestRecord.lock
${SYMROOT}/.TargetConfigTestRecord.plist
Mac OS X March 12, 2008 Mac OS X