Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

tconf(1) [osx man page]

tconf(1)						    BSD General Commands Manual 						  tconf(1)

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
Man Page