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 infor-
mation 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 con-
tained 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 envi-
ronment variable is not set, the value "Default" is used.
The main options to tconf are usually used one at a time per call. How-
ever, 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 occur-
rences 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. Other-
wise, 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 property list) will
print "YES" to standard output if the value of the variable is true, oth-
erwise "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" sec-
tion in the property list, all feature queries are automat-
ically 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 stan-
dard output, but the output can be written to a specified file by suffix-
ing 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 previously
recorded --test feature queries (also mentioned above, in the Note sec-
tion), will be used. In this case, it is suggested that all --test fea-
ture 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
Mac OS X 10.6 - Generated Thu Sep 17 20:09:19 CDT 2009