//
//  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