//
// cctools.xcconfig
// cctools
//
// Created by Michael Trent on 12/20/18.
//
// Configuration settings file format documentation can be found at:
// https://help.apple.com/xcode/#/dev745c5c974
// Project versions are plumbed through the cctools project as follows:
//
// B&I will set RC_ProjectSourceVersion and RC_ProjectNameAndSourceVersion
// when building the cctools project. RC_ProjectSourceVersion is the cctools
// source version, e.g., 930.9.1. RC_ProjectNameAndSourceVersion is the
// 'cctools-930.9.1' pair.
//
// Xcode provides CURRENT_PROJECT_VERSION for holding the
// RC_ProjectSourceVersion. The cctools project will explicitly set
// CURRENT_PROJECT_VERSION to the contents of RC_ProjectSourceVersion.
//
// The cctools project provides a default value of RC_ProjectSourceVersion,
// 1, to be used when cctools is built outside of B&I, buildit, or the
// version is not otherwise passed on the command line. Similarly,
// RC_ProjectNameAndSourceVersion has a default value of "cctools-localbuild".
//
// This information is used in a couple of ways:
//
// RC_ProjectNameAndSourceVersion will be passed to libstuff's
// apple_version.c file.
//
// RC_ProjectSourceVersion is used to set libmacho's current version number.
CURRENT_PROJECT_VERSION = ${RC_ProjectNameAndSourceVersion}
RC_ProjectNameAndSourceVersion = cctools-localbuild
RC_ProjectSourceVersion = 1
// cctools builds are heavily dependent on context and configuration from B&I
// build train settings. To ease project maintenance, all of the RC_ variables
// consumed by the cctools project are consulted here and only here. This way
// we can easily audit what settings are used by cctools and easily change the
// project as these values are added or removed.
CCTB_MACOS = ${RC_MACOS} // YES or (NULL)
CCTB_IOS = ${RC_IPHONE} // YES or (NULL)
CCTB_WATCHOS = ${RC_WATCH} // YES or (NULL)
CCTB_TVOS = ${RC_APPLETV} // YES or (NULL)
CCTB_BRIDGEOS = ${RC_BRIDGE} // YES or (NULL)
CCTB_XCODE = ${RC_DEVTOOLS} // YES or (NULL)
CCTB_PROJECT = ${RC_ProjectName}
CCTB_PROJVERS = ${RC_ProjectNameAndSourceVersion}
CCTB_VERSION = ${RC_ProjectSourceVersion}
// Currently B&I will set INSTALL_LOCATION before building cctools in order
// to control the location of cctools at build time. Ideally the install
// destinations would be owned by cctools, as documented here:
//
// <rdar://problem/28576945> Can cctools stop relying on $ENV{'INSTALL_LOCATION'}
//
// Towards that end, all usage of INSTALL_LOCATION will be encapsulated here,
// in CCTOOLS_LOCATION, giving us a single point to configure where CCTOOLS
// should be installed.
//
// CCTOOLS_LOCATION will be set in two separate indirection passes. The first
// indirection is based on build alias name (RC_ProjectName). This may lead
// to a second level of indirection based on train platform (RC_MACOS, etc.).
// This avoids embedding large, unwieldy tables of values in our value names.
// Instead, we build a number of small, unwieldy tables ...
//
// MDT TODO: Should we use TOOLCHAIN_INSTALL_DIR instead of DT_TOOLCHAIN_DIR?
//
// <rdar://problem/20656765> Drive tools projects to adopt TOOLCHAIN_INSTALL_DIR instead of DT_TOOLCHAIN_DIR
// <rdar://problem/20656786> Set TOOLCHAIN_INSTALL_DIR in additional to DT_TOOLCHAIN_DIR for specifying toolchain install path
// second level (build train) CCTOOLS_LOCATION lookups:
CCTOOLS_LOCATION2_TOOLS_FOR_MAC_OR_DT_YES = ${DT_VARIANT}${DT_TOOLCHAIN_DIR}
CCTOOLS_LOCATION2_OFILES_SIM_FOR_BRIDGE_YES = ${DEVELOPER_DIR}/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator${IPHONE_SDK_MARKETING_VERSION}.sdk
// first level (build alias) CCTOOLS_LOCATION lookups:
CCTOOLS_LOCATION1_cctools = ${CCTOOLS_LOCATION2_TOOLS_FOR_MAC_OR_DT_${CCTB_MACOS}${CCTB_XCODE}}
CCTOOLS_LOCATION1_cctools_ofiles_driverkit = ${DRIVERKITROOT}
CCTOOLS_LOCATION1_cctools_ofiles_Sim = ${CCTOOLS_LOCATION2_OFILES_SIM_FOR_BRIDGE_${CCTB_BRIDGEOS}}
CCTOOLS_LOCATION1_cctools_sdk = ${DT_VARIANT}${DT_TOOLCHAIN_DIR}
// abstract assignment of CCTOOLS_LOCATION:
CCTOOLS_LOCATION = ${CCTOOLS_LOCATION1_${CCTB_PROJECT}}
// additional helpers that individual targets will use to form ${INSTALL_PATH}
CCTOOLS_USRBIN = ${CCTOOLS_LOCATION}/usr/bin
CCTOOLS_USRLOCAL = ${CCTOOLS_LOCATION}/usr/local
CCTOOLS_USRLOCALBIN = ${CCTOOLS_LOCATION}/usr/local/bin
CCTOOLS_USRLIBEXEC = ${CCTOOLS_LOCATION}/usr/libexec
CCTOOLS_USRLOCALLIBEXEC = ${CCTOOLS_LOCATION}/usr/local/libexec
CCTOOLS_USRMAN = ${CCTOOLS_LOCATION}/usr/share/man
CCTOOLS_USRLOCALMAN = ${CCTOOLS_LOCATION}/usr/local/share/man
CCTOOLS_RELNOTES = ${CCTOOLS_LOCATION}/usr/local/RelNotes
CCTOOLS_EFI = ${CCTOOLS_LOCATION}/usr/local/efi
// cctools is part of libsystem and cannot use modules
CLANG_ENABLE_MODULES = NO
// Filter out local build files from project sources, incase one builds in
// one's project directory ...
EXCLUDED_INSTALLSRC_SUBDIRECTORY_PATTERNS = $(inherited) build DerivedData
// For historical reasons, all cctools project builds recursively include the
// "include" subdirectory
HEADER_SEARCH_PATHS = include/**
INSTALL_MODE_FLAG = a=rX
// cctools provides its own overrides for certain CoreOS headers. Clang will
// complain quite loudly about this particular situation, and so the warning is
// disabled here.
OTHER_CFLAGS = -Wno-ambiguous-macro