Version 11 (modified by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), 5 years ago) (diff) |
---|
Command Line Options
The behavior of compilers are primarily controlled with switches. For example, -I${prefix}/include
and -L${prefix}/lib
tell the C preprocessor and linker to look in the MacPorts prefix for header files and libraries respectively. However, changing compiler behavior with switches can cause problems.
- Order matters.
-I${prefix}/include -I${worksrcpath}/include
and-I${worksrcpath}/include -I${prefix}/include
produce different results if different header files with the same name are in both location.- Such errors can be subtle and difficult to track down, especially when the header files are from different versions of the same packages (e.g. during the upgrade process).
- The MacPorts construct
conflicts_build
can be used to prevent the conflicting header files from being simultaneously installed, but this not ideal. - Using
-isystem
instead of-I
can more precisely control search order, but this also causes problems. - The search order for libraries has similar problems, but it is more difficult to precisely control library search order (there is just
-L
or using the full library path name). - The MacPorts buildbot is careful to build a port only with the minimal set of dependencies active, which prevents most search order issues.
- Switches can be “baked in” the installed files.
- Some packages record the history of the switches they were built with.
- Some packages use the same switches they were built with to build other packages.
- At best, this is unnecessary noise. At worst, it causes build problems that can be difficult to diagnose.
- The switches
-isysroot
and-Wl,-syslibroot
are particularly problematic.- Major upgrades of Xcode usually remove old SDKs.
- After a user upgrades Xcode, ports can mysteriously stop building correctly.
- If the Xcode versions of the user and buildbot are different, ports can fail to build correctly.
Environment Variables
To a limited extent, the behavior of compilers can also be controlled with environment variables instead of switches.
Switch | Variable | Affect | Notes |
---|---|---|---|
-I | CPATH | treated as a delimited list of paths to be added to the default system include path list | |
-L | LIBRARY_PATH | tries the directories specified when searching for special linker files | |
-mmacosx-version-min | MACOSX_DEPLOYMENT_TARGET | the default deployment target | |
-isysroot , -Wl,-syslibroot | SDKROOT | specifies the SDK | |
DEVELOPER_DIR | tells xcrun where to search for development tools and properties | ||
CC_PRINT_OPTIONS | like -v but logs the commands | interferes with-v
| |
CC_PRINT_OPTIONS_FILE | the file to log CC_PRINT_OPTIONS output to |
Using environment variables can alleviate some of the problems with switches.
- They are less likely to be “baked in” the installed files.
- Directories in CPATH and LIBRARY_PATH are searched after those specified by the command line options.
However, an environment variable is no panacea.
- Not all build systems respect environment variables.
- Not all environment variables are supported on all compilers.
- Setting CC_PRINT_OPTIONS causes
-v
to behave differently. For example, it breaks FindOpenMP in CMake.
Variable | Xcode Support | Clang Support | GCC Support |
---|---|---|---|
CPATH | all except early versions of Clang (1.*) | all available from MacPorts | all available from MacPorts |
LIBRARY_PATH | all except early versions of Clang (1.*) | all available from MacPorts | all available from MacPorts |
MACOSX_DEPLOYMENT_TARGET | all | all available from MacPorts | all available from MacPorts |
SDKROOT | OSX 10.9 (existence of /usr/lib/libxcselect.dylib) | all available from MacPorts | version 9+ |
DEVELOPER_DIR | OSX 10.9 (existence of /usr/lib/libxcselect.dylib) | N/A | N/A |
CC_PRINT_OPTIONS | all | all available from MacPorts | all available from MacPorts |
CC_PRINT_OPTIONS_FILE | all | all available from MacPorts | all available from MacPorts |