|
|
This manual page is for Mac OS X version 10.6.3If you are running a different version of Mac OS X, view the documentation locally:
Reading manual pagesManual pages are intended as a quick reference for people who already understand a technology.
|
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 variable 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. Otherwise, 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 tar-get target
get conditional variable (from the "TargetConditional" section of the property 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 multi-ple multiple
ple 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 fea-ture feature
ture availability. If a type:name pair is not found in the "Features" section, "NO" is returned, inde-pendent independent
pendent 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 automati-cally automatically
cally 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 sys-tem-supplied system-supplied
tem-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 speci-fied specified
fied 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 environ-ment environment
ment (as mentioned above), the previously 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 evalu-ated evaluated
ated 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
|
The way to report a problem with this manual page depends on the type of problem: