facebookarchive / xcbuild Goto Github PK

Xcode-compatible build tool.

License: Other

CMake 2.09% C++ 95.12% C 2.76% Makefile 0.03%

xcbuild's Introduction

xcbuild

xcbuild is an Xcode-compatible build tool with the goal of providing faster builds, better documentation of the build process and running on multiple platforms (macOS, Linux, and Windows)

Why xcbuild?

Features		Performance
🚀	Blazing fast incremental builds		`xcodebuild`	xcbuild + Ninja
📖	Documents the Xcode build process
🔗	Builds Xcode projects and workspaces
🐣	Supports Swift apps and frameworks	Clean Build	30.103s	25.122s
✨	Tools and libraries for Xcode projects
💝	Fully compatible with xcpretty
🎩	Uses Ninja and llbuild	Incremental Build	2.190s	0.046s ⚡
	Open source under the BSD license
🐧	Builds on Linux and Windows

xcbuild and other build tools

xctool	Buck	xcpretty
xcbuild and xctool are both Xcode-compatible build systems. We plan on slowly deprecating xctool's build support but keep it as a great way to run tests.	Facebook's main build system is Buck. Buck has a stronger architecture and advanced features like artifact caching while having a much simpler build format. If you have a new project, it's highly recommended.	xcbuild works great with xcpretty. Pipe the output from xcbuild to xcpretty the same way as you would from `xcodebuild`.

Building xcbuild

Requirements

All platforms

CMake and Ninja (or llbuild) are required to build xcbuild.

On macOS you can install those tools with Homebrew: brew install cmake ninja.

On Windows you can install those tools with Chocolatey: choco install cmake ninja.

Linux

Ubuntu 18.04

sudo apt install libpng-dev libpng16-16 libxml2-dev pkg-config ninja-build

All others

GCC 4.8 or later. libpng16-dev, zlib1g-dev, libxml2-dev, and pkg-config are also required.

FreeBSD

FreeBSD 12.1

pkg install png-1.6.37 libxml2-2.9.9 pkgconf-1.6.3,1 ninja-1.9.0,2 gmake-4.2.1_3

OpenBSD

OpenBSD 6.6

pkg_add png-1.6.37 libxml-2.9.9 pkgconf-1.6.3 ninja-1.9.0 gmake-4.2.1p4

macOS

Xcode 7 or later.

Windows

Visual Studio 2015 or later, on Windows. A zlib DLL is also required.

Instructions

All platforms

git clone --depth=1 https://github.com/facebook/xcbuild
cd xcbuild
git submodule update --init

Linux and macOS:

make

FreeBSD and OpenBSD:

gmake

Build output will be in the build directory. Run xcbuild with ./build/xcbuild.

You can place xcbuild in your bin directory to run it from other locations: mv build/xcbuild /usr/local/bin/.

Windows (experimental):

cmake -Bbuild -H. -G "Visual Studio 14 2015" -DZLIB_ROOT=<path>

Open build\xcbuild.sln and build.

Usage

The command line options are compatible with xcodebuild.

xcbuild -workspace Example.xcworkspace -scheme Example

Using Ninja (or llbuild)

To switch to the significantly faster Ninja executor:

xcbuild -executor ninja [-workspace Example.xcworkspace ...]

Besides the -executor ninja parameters, the options are otherwise identical. The Ninja executor is fastest if it can avoid re-generating the Ninja files if the build configuration and input project files do not change.

Contributing

xcbuild actively welcomes contributions from the community. If you're interested in contributing, be sure to check out the contributing guide. It includes some tips for getting started in the codebase, as well as important information about the code of conduct, license, and CLA.

Thanks

xcbuild is built on build system documentation from the community. In particular, thanks to these people for their writing:

Third-party licenses are listed in the LICENSE document.

xcbuild's People

Contributors

Stargazers

Watchers

Forkers

roman-dzieciol nong123 sarvex ezhangle maxprig wdxgtsh programming086 neojoke transformersprimeabcxyz xyxjn hj3938 yyinhai forcha keithlee208 imjerrybao geasscode useringo chengxxxxwang k214k xuvw lol666666 zeus911 chaiwa-berian tolecen rather gillbates tcgloveacm royalwang sheepyellow iyangming neochow runt18 ktwu guanwei marcsalem g33kyaditya daerwang kleopatra999 kphillisjr modocache matthewbauer husshazein stlwtr samerel-daoor kolinkrewinkel sas bambies jackwu95 gfosco fireword nariss001 narissiam seungwooyu leminhtuan2015 brtsai phamquyhai lizixroy cc-plum copumpkin webxzy wenyanningwork crazypoo mstorsjo wh33t01 fsp1990 compnerd forkrp kitty2014 liqt trikyas alexxnica kryndex dklinzh cstars135 krausefx strager charlieyqin elemon8r tomarron ryuichis speedynassir flarnie avaneyev umlaeute sepatus88 lacbs opportunitylivetv happy-ferret evifree arielelkin ralic sarmadafzal 0x5e darlinghq liuxiangdong3721 kerasking zhaishuai zhzpower trarck junyixie

xcbuild's Issues

Build failed on Copy Headers due to lack of permissions

I am getting a new build failure due to lack of permissions on a copy headers build phase. If i execute with sudo there is no issue (obviously). The header that it fails on is not consistent, not sure if that is indicative of anything or not.

$ ./xcbuild -workspace ~/Desktop/cats/Catstagrame.xcworkspace -scheme Bot
=== BUILD TARGET AFNetworking OF PROJECT Pods WITH THE DEFAULT CONFIGURATION (Debug) ===

Check dependencies

Write auxiliary files
write-file /Users/sam/Library/Developer/Xcode/DerivedData/Catstagrame-dpgoibticpelzsdklobltuyhxmbi/Build/Intermediates/Pods.build/Debug-iphoneos/AFNetworking.build/AFNetworking.hmap
write-file /Users/sam/Library/Developer/Xcode/DerivedData/Catstagrame-dpgoibticpelzsdklobltuyhxmbi/Build/Intermediates/Pods.build/Debug-iphoneos/AFNetworking.build/AFNetworking-own-target-headers.hmap
write-file /Users/sam/Library/Developer/Xcode/DerivedData/Catstagrame-dpgoibticpelzsdklobltuyhxmbi/Build/Intermediates/Pods.build/Debug-iphoneos/AFNetworking.build/AFNetworking-all-target-headers.hmap
write-file /Users/sam/Library/Developer/Xcode/DerivedData/Catstagrame-dpgoibticpelzsdklobltuyhxmbi/Build/Intermediates/Pods.build/Debug-iphoneos/AFNetworking.build/AFNetworking-all-non-framework-target-headers.hmap
write-file /Users/sam/Library/Developer/Xcode/DerivedData/Catstagrame-dpgoibticpelzsdklobltuyhxmbi/Build/Intermediates/Pods.build/Debug-iphoneos/AFNetworking.build/AFNetworking-generated-files.hmap
write-file /Users/sam/Library/Developer/Xcode/DerivedData/Catstagrame-dpgoibticpelzsdklobltuyhxmbi/Build/Intermediates/Pods.build/Debug-iphoneos/AFNetworking.build/AFNetworking-project-headers.hmap
write-file /Users/sam/Library/Developer/Xcode/DerivedData/Catstagrame-dpgoibticpelzsdklobltuyhxmbi/Build/Intermediates/Pods.build/Debug-iphoneos/AFNetworking.build/Objects-normal/arm64/AFNetworking.LinkFileList
write-file /Users/sam/Library/Developer/Xcode/DerivedData/Catstagrame-dpgoibticpelzsdklobltuyhxmbi/Build/Intermediates/Pods.build/Debug-iphoneos/AFNetworking.build/Objects-normal/armv7/AFNetworking.LinkFileList

Create product structure

CpHeader /Users/sam/Library/Developer/Xcode/DerivedData/Catstagrame-dpgoibticpelzsdklobltuyhxmbi/Build/Products/Debug-iphoneos//UIWebView+AFNetworking.h /Users/sam/Desktop/cats/Pods//AFNetworking/UIKit+AFNetworking/UIWebView+AFNetworking.h
    cd /Users/sam/Desktop/cats/Pods/
    builtin-copy -exclude CVS -exclude .svn -exclude .git -exclude .hg -strip-tool /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip -bitcode-strip-tool /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/bitcode_strip /Users/sam/Desktop/cats/Pods//AFNetworking/UIKit+AFNetworking/UIWebView+AFNetworking.h /Users/sam/Library/Developer/Xcode/DerivedData/Catstagrame-dpgoibticpelzsdklobltuyhxmbi/Build/Products/Debug-iphoneos/
cp: /Users/sam/Library/Developer/Xcode/DerivedData/Catstagrame-dpgoibticpelzsdklobltuyhxmbi/Build/Products/Debug-iphoneos//UIWebView+AFNetworking.h: Permission denied

** BUILD FAILED **

The following build commands failed:
    CpHeader /Users/sam/Library/Developer/Xcode/DerivedData/Catstagrame-dpgoibticpelzsdklobltuyhxmbi/Build/Products/Debug-iphoneos//UIWebView+AFNetworking.h /Users/sam/Desktop/cats/Pods//AFNetworking/UIKit+AFNetworking/UIWebView+AFNetworking.h
(1 failure)

Support for plugins?

Will this tool offer a simillar api for plugins? I am thinking of specifically plugins based on the xcspec files, while those are very few (I think I've written the only one) I do think it would be ideal for future compatibility and support during betas.

Support INFOPLIST_PREPROCESS and related build settings

I noticed that some of the property list files being built by xcbuild are not formatted correctly. I found a few example property lists that show generic examples that most developers will try to use in preprocessing of these files. In general this preprocessor works as a C Preprocessor with a few quirks added. Some notes on this can be found on Apple Technical Note TN2175.

In general I would assume that the plist utility will support the following operations...

Pre-processor Conditionals: #if, #ifdef, #ifndef, #else, #elif and #endif.
C-style Relational Operators ( see: Wikipedia: Operators in C and C++ )
C-style Logical Operators ( see: Wikipedia: Operators in C and C++ )
C-Style comments /* Comment */
C++-Style comments // Comment ( when -traditional is not set )

Example 1: IOAudioFamily version 204.3
This is the one of the simplest examples of plist editing. All it does is define a few variables in an xcode configuration file and output it in the kernel extensions PLIST file..

Example 2: IOHIDFamily version 701.20.10
A slightly more complex example. This configures multiple property lists.

Example 3: IOStorageFamily version 191
This includes an example of preprocessor events to remove sections of the property list on a Embedded platform where TARGET_OS_EMBEDDED is defined in the TargetConditionals header.

Example 4: Some more Pre-processor examples.
For the most part if it's in the TargetConditionals header for OSX, it'll appear in the Property list utility.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>PreProcess_KEYS</key>
    <dict>
        <key>IsEmbedded</key>
#if !TARGET_OS_EMBEDDED
        <true/>
#else 
        <false/>
#endif

        <key>IsMac</key>
#if TARGET_OS_MAC
        <true/>
#else 
        <false/>
#endif
        <key>IsPowerPC</key>
#if TARGET_CPU_PPC
        <true/>
#else 
        <false/>
#endif
    </dict>
</dict>

Crash from master (f24cfe6) in libpbxbuild

Building a standard iOS app target plus some dependencies.
xcbuild_2016-01-28-093552_Pegasus.txt

I am seeing this on a number of projects, some of them have no special attributes at all, both OS X and iOS targets are used.

bug: target should be a tuple.

The target argument with the stock xcodebuild utility works as a tuple when it has repeated entries. A valid example of how this works can be accomplished by trying to build a couple of the commonly used dtrace utilities.

# Download dtrace version 168 from apple.
curl -O https://opensource.apple.com/tarballs/dtrace/dtrace-168.tar.gz
tar zxf dtrace-168.tar.gz
cd dtrace-168
mkdir -p obj sym dst
# build ctfconvert, ctfdump, and ctfmerge targets using one command.
xcodebuild -target ctfconvert -target ctfdump -target ctfmerge ARCHS="x86_64" SRCROOT=$PWD OBJROOT=$PWD/obj SYMROOT=$PWD/sym DSTROOT=$PWD/dst
# Install (and build) ctfconvert, ctfdump, and ctfmerge targets using one command.
xcodebuild install -target ctfconvert -target ctfdump -target ctfmerge ARCHS="x86_64" SRCROOT=$PWD OBJROOT=$PWD/obj SYMROOT=$PWD/sym DSTROOT=$PWD/dst

Add a Path class to represent file paths.

Right now, xcbuild represents file paths as std::strings and constructs them with string concatenation. This works OK, but it's easy to get confused between a path and another kind of string, and easy to incorrectly format combined paths (extra trailing or duplicate slashes are common).

The solution here is to create a path type that keeps a list of file path components, and replaces std::string.

Ship as a gem (or via homwbrew) instead of only as source?

Hi,

How difficult would it be to ship this as a gem instead of having to build from source? We already use xcpretty as a gem on our CI agents, and having a stable gem for this as well would make our lives much much easier :)

Another alternative might be homebrew like xctool?

Thanks,
Sam

Support runOnlyForDeploymentPostprocessing [was: Build fails when doesn't have permission to copy man page]

Input for xcbuild:

$ ./xcbuild -workspace ~/Projects/SDMMobileDevice/SDMMobileDevice.xcworkspace -scheme iOSConsole

Output from xcbuild:

PBXCp //usr/share/man/man1//iOSConsole.1 /Users/sam/Projects/SDMMobileDevice/iOSConsole/iOSConsole/iOSConsole.1
    cd /Users/sam/Projects/SDMMobileDevice/iOSConsole
    builtin-copy -exclude CVS -exclude .svn -exclude .git -exclude .hg -strip-tool /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip -bitcode-strip-tool /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/bitcode_strip /Users/sam/Projects/SDMMobileDevice/iOSConsole/iOSConsole/iOSConsole.1 //usr/share/man/man1/
cp: //usr/share/man/man1//iOSConsole.1: Permission denied

** BUILD FAILED **

The following build commands failed:
    PBXCp //usr/share/man/man1//iOSConsole.1 /Users/sam/Projects/SDMMobileDevice/iOSConsole/iOSConsole/iOSConsole.1
(1 failure)

I don't see xcodebuild performing the same step and the build succeeds.

State of project on Linux

It's not entirely clean for me how it can be used on Linux.

Should I copy the necessary Apple SDKs to somewhere on the Linux machine? If not, where Cocoa symbols come from?

Thanks!

Ambiguous error message when not specifying scheme with workspace

When running xcbuild on a workspace without a scheme specified it should output a more helpful and less ambiguous error message.

$ ./xcbuild -workspace ~/Desktop/cats/Catstagrame.xcworkspace
error: unable to determine build configuration

$ xcodebuild -workspace ~/Desktop/cats/Catstagrame.xcworkspace
xcodebuild: error: If you specify a workspace then you must also specify a scheme.  Use -list to see the schemes in this workspace.

Missing PBX types

In the ISA.cpp file you seem to be missing the following PBX types:

PBXApplicationReference
PBXApplicationTarget
PBXBundleReference
PBXBundleTarget
PBXExecutableFileReference
PBXFrameworkReference
PBXFrameworkTarget
PBXJavaArchiveBuildPhase
PBXLibraryReference
PBXLibraryTarget
PBXRezBuildPhase
PBXStandAloneTarget
PBXToolTarget
PBXZipArchiveReference

make fails when trying to compile third party tests

I'm on Linux with gcc 5.3.0, cmake 3.4.3, and ninja 1.6.0

This is the output I'm getting when running the make command inside the xcbuild directory:

mkdir -p build
cmake -Bbuild -H. -G Ninja
-- The C compiler identification is GNU 5.3.0
-- The CXX compiler identification is GNU 5.3.0
-- Check for working C compiler using: Ninja
-- Check for working C compiler using: Ninja -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler using: Ninja
-- Check for working CXX compiler using: Ninja -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PythonInterp: /usr/bin/python (found version "2.7.6")
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Found LibXml2: /usr/lib/x86_64-linux-gnu/libxml2.so (found version "2.9.1")
-- Configuring done
-- Generating done
-- Build files have been written to: /home/ubuntu/xcbuild/build
ninja -C build
ninja: Entering directory `build'
[5/324] Building CXX object Libraries/libutil/CMakeFiles/util.dir/Sources/SysUtil.cpp.o
FAILED: /usr/bin/c++   -Dutil_EXPORTS -I../Libraries/libutil/Headers -std=c++11 -Wall -Werror -Wno-sign-compare -fdiagnostics-color -g -fPIC -MMD -MT Libraries/libutil/CMakeFiles/util.dir/Sources/SysUtil.cpp.o -MF Libraries/libutil/CMakeFiles/util.dir/Sources/SysUtil.cpp.o.d -o Libraries/libutil/CMakeFiles/util.dir/Sources/SysUtil.cpp.o -c ../Libraries/libutil/Sources/SysUtil.cpp
../Libraries/libutil/Sources/SysUtil.cpp: In static member function ‘static std::string libutil::SysUtil::GetExecutablePath()’:
../Libraries/libutil/Sources/SysUtil.cpp:88:21: error: ‘assert’ was not declared in this scope
         assert(false);
                     ^
[5/324] Building CXX object ThirdParty/googletest/googletest/CMakeFiles/gtest.dir/src/gtest-all.cc.o
ninja: build stopped: subcommand failed.
make: *** [all] Error 1

Implement PlistBuddy for non-OSX Platforms

This is not exactly a commonly used tool, but this tool is especially important since it enables shell scripts to modify Property List files from the command line with ease. To get a general idea on how this utility works, look at the Apple Mac OS X Manual Page: PlistBuddy(8). I also know that there is a blog post titled "OSX: Dealing with property list files" that can help with this.

Also as a quick note, on OSX this utility is installed as... /usr/libexec/plistbuddy

Failed to resolve build action entry

warning: couldn't find buildable reference for build action entry

reproducible with https://github.com/mtitolo/cats

installing xcbuild fails with cmake error: "Could NOT find PNG"

Add read support for JSON to plist

Right now, xcbuild supports Binary, ASCII, and XML plists. JSON is a similar format and the implementations of some tools (e.g. plutil) expect it to be available.

The plist module in xcbuild is designed to be extensible, so this should be relatively simple to implement. To do it, you'll first need to add a new header for a class plist::Format::JSON that implements plist::Format::Format<JSON>. This class represents the possible options for the format; for JSON, this is likely to be empty as the encoding is fixed to UTF-8.

Finally, implement the plist::Format::Format methods to identify, deserialize, and serialize JSON. This might be easiest with an existing JSON library. For deserialization, you'll probably want to maintain a stack of the current array/dictionary path as you parse. For serialization, it might be easier to manually recursively write out the format rather than using a library; the ASCII format might be instructive here.

For a complete reference, the XML plist format in xcbuild might be useful:

Header: https://github.com/facebook/xcbuild/blob/master/Headers/plist/Format/XML.h
Implementation: https://github.com/facebook/xcbuild/blob/master/Sources/plist/Format/XML.cpp
Parser implementation (using expat): https://github.com/facebook/xcbuild/blob/master/Sources/plist/Format/XMLParser.cpp
Serialization implementation: https://github.com/facebook/xcbuild/blob/master/Sources/plist/Format/XMLWriter.cpp

As always, feel free to ask if you have any questions!

Shell script phase environment variable export should be limited to build settings [was: Shell script phase pull variables in from shell environment]

I am noticing the variables I use to configure my shell environment being outputted in the export of variables done by the shell script phase. The phases run by Xcode exist in an isolated environment from what the user's shell has. This is to prevent conflicts with variable name resolution and settings. The script phases should not inherit these values.

xcbuild: add linux SDK Definition

Due to the nature of how xcbuild works I figured it would not hurt to allow developers to compile various projects to run on linux directly. Some of these might take more work than others, but a few examples of projects that should have the ability to be compiled under linux with slight modification is as follows...

Apple cctools - http://opensource.apple.com/tarballs/cctools/cctools-877.8.tar.gz
clang (with apple changes)- http://opensource.apple.com/tarballs/clang/clang-700.1.81.tar.gz
ld64 - http://opensource.apple.com/tarballs/ld64/ld64-253.9.tar.gz
bootstrap_cmds - http://opensource.apple.com/tarballs/bootstrap_cmds/bootstrap_cmds-93.tar.gz
developer_cmds - http://opensource.apple.com/tarballs/developer_cmds/developer_cmds-62.tar.gz
dtrace - http://opensource.apple.com/tarballs/dtrace/dtrace-168.tar.gz

Build succeeds when it should fail on error from missing SDK

$ 
./xcbuild -project ~/Projects/EFIFaker/EFIFaker.xcodeproj -scheme EFIFaker
=== BUILD TARGET EFIFaker OF PROJECT EFIFaker WITH THE DEFAULT CONFIGURATION (Release) ===

error: unable to find sdkroot macosx10.9
error: couldn't create target environment for EFIFaker
** BUILD SUCCEEDED **

I think in this scenario the build should fail because of the errors in resolving the SDK bundle.

Replace FSUtil with a Filesystem object.

Right now, libutil::FSUtil is used for file operations throughout xcbuild. This can make calling into code potentially dangerous if it makes changes to the filesystem, and there's nothing in the API that makes it clear that's going to happen.

A better alternative would be a Filesystem object that represents the state of the file system. This has two benefits. First, if some code wants one, you'll have to have one passed from above making it very clear that the code can either access (const) or modify (non-const) the filesystem. Second, a stub filesystem could make testing this code much easier.

First step for this is to add a Filesystem class to libutil, and make FSUtil use it. After that, can start looking at updating the rest of the code to pass through the Filesystem object.

Copy header phase happens before compile phase

I'm noticing on the output of xcbuild that it will output the copy-header phases before performing a compile, this doesn't respect the ordering that Xcode has for a build or the ordering that the phases have in the project file.

Support for codesigning binaries

The ability to codesign binaries upon build would be great to have, reading from CODE_SIGN_IDENTITY and CODE_SIGN_ENTITLEMENTS.

One thing I didn't realize until recently is that ldid supports full codesigning, so to be able to use either codesign (OS X-only) or ldid (cross platform) to sign the binary would be awesome.

Move submodule dependencies to a more stable hosted solution

I have been trying to checkout the repo but I'm currently stuck on pulling modules as SourceForge seems to be down currently. Given the recent issues with SourceForge modifying open-source project downloads, it might be advisable to move to a more secure/stable hosted solution for these dependencies.

Samantha@Pegasus:~/Projects/xcbuild $ git submodule update --init                                                                       (master ⚡=)
Cloning into 'ThirdParty/expat'...
fatal: unable to connect to git.code.sf.net:
git.code.sf.net[0: 216.34.181.155]: errno=Operation timed out

Clone of 'git://git.code.sf.net/p/expat/code_git' into submodule path 'ThirdParty/expat' failed

Implement -help command line option

xcbuild has a -help option to explain the usage of the tool. Right now, this option is unimplemented.

To implement this, change Driver.cpp in xcdriver to call into HelpAction::Run(). Then, create a HelpAction class and implement the Run() method to print out usage info.

Install actions not implemented.

I was giving xcbuild a quick test run on unit testing and found that the various install actions are not working. The two main Install actions users will use are installing headers and installing the product.

# Install Header files.
xcodebuild installhdrs

# Build and install product.
xcodebuild install

Also as a quick note installhdrs involves two new attributes for PBXBuildFile these attributes are under the tag ATTRIBUTES. The first Attribute is Public and this is set if the header file goes into the public header directory. The second Attribute is Private, and this will install the header to the private header directory.

Xcode build directory preferences are not respected

I think this qualifies as a problem with xcbuild if it intends to support building from xcodeproj files. Depending on how the project file and build paths are configured you may or may not have a successful build depending on which tool (xcodebuild vs xcbuild) you use. You can see what I do https://github.com/samdmarshall/pyxcrunhelper/blob/develop/xcrunHelper/xcrun.py#L61 to resolve this value of the original build directory. Right now it looks like xcbuild defaults to using a derived data path even though my Xcode preferences are set to use a directory specified by $(SYMROOT) per target.

CMake Error: Could not create named generator Ninja

Getting this error while trying to build xcbuild on Linux:

ubuntu@box1507:~/ios9-examples-linux/xcbuild$ make
mkdir -p build
cmake -Bbuild -H. -G Ninja
CMake Error: Could not create named generator Ninja
make: *** [all] Error 1

I am on Ubuntu Precise, ninja version is 1.3.4, cmake version is 2.8.7, GCC version is 5.2.1 20151031, libxml2-dev is 2.7.8. Am I missing something?

sdkroot does not follow symlinks, so the build fails, but reports as succeeded

Because every time you install a new version of XCode these days it wipes all older SDKs, I keep them stored elsewhere on my machine and have a script to setup links inside /Applications/XCode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs

This works fine for XCodeBuild, but when I tried building the same project with XCBuild, I got a stream of

"error: unable to find sdk root"

for each target.

So it doesn't build anything

But at the end, in bright green letters, its says

** BUILD SUCCEEDED **

So it would seem I'm looking at two bugs, one which results in the build failing, the other which results in that not being reported properly

Set CMake policy for MACOSX_RPATH to suppress developer warning

I ran make and this came up:

CMake Warning (dev):
  Policy CMP0042 is not set: MACOSX_RPATH is enabled by default.  Run "cmake
  --help-policy CMP0042" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.

  MACOSX_RPATH is not specified for the following targets:

   builtin
   dependency
   ext
   ninja
   pbxbuild
   pbxproj
   pbxsetting
   pbxspec
   plist
   util
   xcdriver
   xcscheme
   xcsdk
   xcworkspace

This warning is for project developers.  Use -Wno-dev to suppress it.

Load nested projects at startup [was: Can't specify a scheme in a nested project]

I am noticing when attempting to build a scheme that resides in a child project of the xcodeproj file that I specified via the -project flag I get a warning warning: unhandled Project key projectReferences and then the build proceeds to ignore the scheme I specified via the -scheme flag (the scheme is from the sub-project but is recognized by the parent).

Infinite recursion causes segfault for tvOS builds

https://github.com/facebook/xcbuild/blob/master/Sources/pbxspec/Manager.cpp#L330

    frame #8: 0x00000001008b3819 libpbxspec.dylib`pbxspec::Manager::inheritSpecification(this=0x0000000102001528, specification=std::__1::shared_ptr<pbxspec::PBX::Specification>::element_type @ 0x0000000100fe9bf0 strong=5442 weak=1) + 2393 at Manager.cpp:330
    frame #9: 0x00000001008b3819 libpbxspec.dylib`pbxspec::Manager::inheritSpecification(this=0x0000000102001528, specification=std::__1::shared_ptr<pbxspec::PBX::Specification>::element_type @ 0x0000000100fe9bf0 strong=5442 weak=1) + 2393 at Manager.cpp:330
    frame #10: 0x00000001008b3819 libpbxspec.dylib`pbxspec::Manager::inheritSpecification(this=0x0000000102001528, specification=std::__1::shared_ptr<pbxspec::PBX::Specification>::element_type @ 0x0000000100fe9bf0 strong=5442 weak=1) + 2393 at Manager.cpp:330
    frame #11: 0x00000001008b3819 libpbxspec.dylib`pbxspec::Manager::inheritSpecification(this=0x0000000102001528, specification=std::__1::shared_ptr<pbxspec::PBX::Specification>::element_type @ 0x0000000100fe9bf0 strong=5442 weak=1) + 2393 at Manager.cpp:330
    frame #12: 0x00000001008b3819 libpbxspec.dylib`pbxspec::Manager::inheritSpecification(this=0x0000000102001528, specification=std::__1::shared_ptr<pbxspec::PBX::Specification>::element_type @ 0x0000000100fe9bf0 strong=5442 weak=1) + 2393 at Manager.cpp:330
    frame #13: 0x00000001008b3819 libpbxspec.dylib`pbxspec::Manager::inheritSpecification(this=0x0000000102001528, specification=std::__1::shared_ptr<pbxspec::PBX::Specification>::element_type @ 0x0000000100fe9bf0 strong=5442 weak=1) + 2393 at Manager.cpp:330
    frame #14: 0x00000001008b3819 libpbxspec.dylib`pbxspec::Manager::inheritSpecification(this=0x0000000102001528, specification=std::__1::shared_ptr<pbxspec::PBX::Specification>::element_type @ 0x0000000100fe9bf0 strong=5442 weak=1) + 2393 at Manager.cpp:330
...
    frame #5446: 0x00000001008b3819 libpbxspec.dylib`pbxspec::Manager::inheritSpecification(this=0x0000000102001528, specification=std::__1::shared_ptr<pbxspec::PBX::Specification>::element_type @ 0x0000000100fe9bf0 strong=5442 weak=1) + 2393 at Manager.cpp:330
    frame #5447: 0x00000001008b4f9f libpbxspec.dylib`pbxspec::Manager::registerDomains(this=0x0000000102001528, domains=size=1) + 4735 at Manager.cpp:420
    frame #5448: 0x00000001002a946f libpbxbuild.dylib`pbxbuild::Target::Environment::Create(buildEnvironment=0x00007fff5fbfe530, buildContext=0x00007fff5fbfddf0, target=std::__1::shared_ptr<pbxproj::PBX::Target>::element_type @ 0x0000000100fd3638 strong=7 weak=1) + 8207 at Environment.cpp:301

Support -destination option

The -destination option accepts a custom syntax to define a run destination to build for. This is used most often for builds containing multiple platforms, as the otherwise-used -sdk would override the SDK for all builds.

The two parts of this are parsing the -destination option syntax, and adjusting build settings as appropriate for each target based on the destination. It would be nice to avoid a dependency on listing available simulators for the supported destinations.

This will be important to be able to build WatchKit apps for watchOS, because they use a related but different platform for different targets in a single scheme.

Add support for VFS-pointed module maps (was: can't find module dependency)

While trying to setup the Lyft project to use xcbuild, I ran into some issues with dependencies. We use CocoaPods to integrated 3rd party, and some first party development dependencies. The structure looks something like this:

Main Project
  -> Alamofire
  -> Internal Library
       -> zipzap
  ...

In this simplified example, the issue we're running into is that zipzap cannot be found. This leads to errors in the Internal Library, and stops us from getting anywhere else.

I've attempted to reproduce the same issue in a sample project:

test-xcbuild4.zip

In this project if you run (with or without specifying -executor ninja):

$ xcbuild -executor ninja -workspace test-xcbuild4 -scheme test-xcbuild4

You will see that it fails to build with the error:

{
  "kind": "finished",
  "name": "compile",
  "pid": 48974,
  "output": "blah blah/AppDelegate.swift:10:8: error: no such module 'zipzap'\nimport zipzap\n       ^\n",
  "exit-status": 1
}

(here's the entire build log)

But if you build from within Xcode, everything compiles correctly.

I would love some advice for where to start when I'm facing errors like this, as I'd love to be able to set our project up to benefit from the speed of Ninja! ⚡

Thanks!

Tag a version to allow releasing on Homebrew

It'd be awesome if I could brew install xcbuild. I'd be happy to submit a Homebrew formula pull request for xcbuild, but it'll need a tagged version in order for me to do so. How about tagging the current HEAD of master as 0.1.0?

Incorrect error when supplying an incorrect scheme name

When supplying a scheme by name that is not matched in the Xcode project or workspace file, I am getting the error:

error: unable to determine build configuration

I think this is incorrect and misleading when the scheme name is misspelled. For reference, this is the error that xcodebuild gives when supplied with a scheme name that it cannot find:

xcodebuild: error: The workspace named "Catstagrame" does not contain a scheme named "bot". The "-list" option can be used to find the names of the schemes in the workspace.

Make xcbuild self-hosting

Right now, xcbuild build using CMake. But it shouldn't be too hard to make an Xcode project for xcbuild — which could then be built by xcbuild itself!

We won't want to get rid of the CMake build system since it'll be needed for bootstrapping on new target platforms, but it shouldn't be too hard to keep both in parallel.

CMake error add_subdirectory(ThirdParty/googletest/googletest)

The add_subdirectory() in the top level CMakeLists.txt calls for the inclusion of /path/to/project/ThirdParty/googletest/googletest, but there is no such direcory. BUILD_TESTING should be ON to see the effect.

xcrun sets SYSROOT but prints SDKROOT

I noticed this while looking at xcrun's source code:

            environment["SYSROOT"] = target->path();

            if (log) {
                printf("env SDKROOT=%s %s\n", target->path().c_str(), executable->c_str());
            }

https://github.com/facebook/xcbuild/blob/master/Libraries/xcsdk/Tools/xcrun.cpp#L415-L423

The first line sets SYSROOT, but the log says SDKROOT. Which one is correct? Is this a bug?

Unhandled property/key DisplayValues

The file Device.xcspec found at path /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/PrivatePlugIns/IDEiOSPlatformSupportCore.ideplugin/Contents/Resources/Device.xcspec contains a enumeration property key that doesn't seem to be supported by xcbuild.

Entry in question:

{   BasedOn = "embedded:com.apple.build-system.native";
        Identifier = "com.apple.build-system.native";
        Properties = (
            {   Basic = "YES";
                Category = "Deployment";
                Description = "The build system uses the selected device to set the correct value for the UIDeviceFamily key it adds to the target's Info.plist file.";
                DisplayName = "Targeted Device Family";
                DisplayValues = ( "iPhone", "iPad", "iPhone/iPad" );
                Name = "TARGETED_DEVICE_FAMILY";
                Type = "Enumeration";
                Values = ( "1", "2", "1,2" );
            },
            {   Category = "BuildOptions";
                DefaultValue = "NO";
                Description = "Activating this setting indicates that the target or project should generate bitcode during compilation for platforms and architectures which support it.  For Archive builds, bitcode will be generated in the linked binary for submission to the app store.  For other builds, the compiler and linker will check whether the code complies with the requirements for bitcode generation, but will not generate actual bitcode. [ENABLE_BITCODE]";
                DisplayName = "Enable Bitcode";
                Name = "ENABLE_BITCODE";
                Type = "Boolean";
            },
        );
        Type = "BuildSystem";
    }

The key DisplayValues is used for the human-readable strings to represent the enumeration values in the Xcode GUI. This doesn't seem to be supported as part of the PropertyOption.cpp parsing.

`make` fails due to unused arguments

Hello,

I followed the build instructions carefully. I am on Ninja 1.6.0 and cmake 3.4.3. When executing make, I get the following output.

Any ideas?

$ make
mkdir -p build
cd build && cmake -G Ninja ..
-- The C compiler identification is AppleClang 7.0.2.7000181
-- The CXX compiler identification is AppleClang 7.0.2.7000181
-- Check for working C compiler using: Ninja
-- Check for working C compiler using: Ninja -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler using: Ninja
-- Check for working CXX compiler using: Ninja -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found LibXml2: /usr/lib/libxml2.dylib (found version "2.9.0") 
-- Found PythonInterp: /usr/local/bin/python (found version "2.7.9") 
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE  
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/cb/Development/xcbuild/build
cd build && ninja 
[10/324] Building CXX object CMakeFiles/plist.dir/Sources/plist/Integer.cpp.o
FAILED: /usr/local/opt/ccache/libexec/c++   -Dplist_EXPORTS -I/usr/include/libxml2 -I../Headers -I../PrivateHeaders -I../ThirdParty/googletest/googletest/include -std=c++11 -Wall -Werror -fcolor-diagnostics -g -fPIC -MMD -MT CMakeFiles/plist.dir/Sources/plist/Integer.cpp.o -MF CMakeFiles/plist.dir/Sources/plist/Integer.cpp.o.d -o CMakeFiles/plist.dir/Sources/plist/Integer.cpp.o -c ../Sources/plist/Integer.cpp
clang: error: argument unused during compilation: '-I /usr/include/libxml2'
clang: error: argument unused during compilation: '-I ../Headers'
clang: error: argument unused during compilation: '-I ../PrivateHeaders'
clang: error: argument unused during compilation: '-I ../ThirdParty/googletest/googletest/include'
[10/324] Building CXX object CMakeFiles/plist.dir/Sources/plist/Null.cpp.o
FAILED: /usr/local/opt/ccache/libexec/c++   -Dplist_EXPORTS -I/usr/include/libxml2 -I../Headers -I../PrivateHeaders -I../ThirdParty/googletest/googletest/include -std=c++11 -Wall -Werror -fcolor-diagnostics -g -fPIC -MMD -MT CMakeFiles/plist.dir/Sources/plist/Null.cpp.o -MF CMakeFiles/plist.dir/Sources/plist/Null.cpp.o.d -o CMakeFiles/plist.dir/Sources/plist/Null.cpp.o -c ../Sources/plist/Null.cpp
clang: error: argument unused during compilation: '-I /usr/include/libxml2'
clang: error: argument unused during compilation: '-I ../Headers'
clang: error: argument unused during compilation: '-I ../PrivateHeaders'
clang: error: argument unused during compilation: '-I ../ThirdParty/googletest/googletest/include'
[10/324] Building CXX object CMakeFiles/plist.dir/Sources/plist/UID.cpp.o
FAILED: /usr/local/opt/ccache/libexec/c++   -Dplist_EXPORTS -I/usr/include/libxml2 -I../Headers -I../PrivateHeaders -I../ThirdParty/googletest/googletest/include -std=c++11 -Wall -Werror -fcolor-diagnostics -g -fPIC -MMD -MT CMakeFiles/plist.dir/Sources/plist/UID.cpp.o -MF CMakeFiles/plist.dir/Sources/plist/UID.cpp.o.d -o CMakeFiles/plist.dir/Sources/plist/UID.cpp.o -c ../Sources/plist/UID.cpp
clang: error: argument unused during compilation: '-I /usr/include/libxml2'
clang: error: argument unused during compilation: '-I ../Headers'
clang: error: argument unused during compilation: '-I ../PrivateHeaders'
clang: error: argument unused during compilation: '-I ../ThirdParty/googletest/googletest/include'
[10/324] Building CXX object CMakeFiles/plist.dir/Sources/plist/UnixTime.cpp.o
FAILED: /usr/local/opt/ccache/libexec/c++   -Dplist_EXPORTS -I/usr/include/libxml2 -I../Headers -I../PrivateHeaders -I../ThirdParty/googletest/googletest/include -std=c++11 -Wall -Werror -fcolor-diagnostics -g -fPIC -MMD -MT CMakeFiles/plist.dir/Sources/plist/UnixTime.cpp.o -MF CMakeFiles/plist.dir/Sources/plist/UnixTime.cpp.o.d -o CMakeFiles/plist.dir/Sources/plist/UnixTime.cpp.o -c ../Sources/plist/UnixTime.cpp
clang: error: argument unused during compilation: '-I /usr/include/libxml2'
clang: error: argument unused during compilation: '-I ../Headers'
clang: error: argument unused during compilation: '-I ../PrivateHeaders'
clang: error: argument unused during compilation: '-I ../ThirdParty/googletest/googletest/include'
[10/324] Building CXX object CMakeFiles/plist.dir/Sources/plist/Base64.cpp.o
FAILED: /usr/local/opt/ccache/libexec/c++   -Dplist_EXPORTS -I/usr/include/libxml2 -I../Headers -I../PrivateHeaders -I../ThirdParty/googletest/googletest/include -std=c++11 -Wall -Werror -fcolor-diagnostics -g -fPIC -MMD -MT CMakeFiles/plist.dir/Sources/plist/Base64.cpp.o -MF CMakeFiles/plist.dir/Sources/plist/Base64.cpp.o.d -o CMakeFiles/plist.dir/Sources/plist/Base64.cpp.o -c ../Sources/plist/Base64.cpp
clang: error: argument unused during compilation: '-I /usr/include/libxml2'
clang: error: argument unused during compilation: '-I ../Headers'
clang: error: argument unused during compilation: '-I ../PrivateHeaders'
clang: error: argument unused during compilation: '-I ../ThirdParty/googletest/googletest/include'
[10/324] Building CXX object CMakeFiles/plist.dir/Sources/plist/Object.cpp.o
FAILED: /usr/local/opt/ccache/libexec/c++   -Dplist_EXPORTS -I/usr/include/libxml2 -I../Headers -I../PrivateHeaders -I../ThirdParty/googletest/googletest/include -std=c++11 -Wall -Werror -fcolor-diagnostics -g -fPIC -MMD -MT CMakeFiles/plist.dir/Sources/plist/Object.cpp.o -MF CMakeFiles/plist.dir/Sources/plist/Object.cpp.o.d -o CMakeFiles/plist.dir/Sources/plist/Object.cpp.o -c ../Sources/plist/Object.cpp
clang: error: argument unused during compilation: '-I /usr/include/libxml2'
clang: error: argument unused during compilation: '-I ../Headers'
clang: error: argument unused during compilation: '-I ../PrivateHeaders'
clang: error: argument unused during compilation: '-I ../ThirdParty/googletest/googletest/include'
[10/324] Building CXX object CMakeFiles/plist.dir/Sources/plist/Real.cpp.o
FAILED: /usr/local/opt/ccache/libexec/c++   -Dplist_EXPORTS -I/usr/include/libxml2 -I../Headers -I../PrivateHeaders -I../ThirdParty/googletest/googletest/include -std=c++11 -Wall -Werror -fcolor-diagnostics -g -fPIC -MMD -MT CMakeFiles/plist.dir/Sources/plist/Real.cpp.o -MF CMakeFiles/plist.dir/Sources/plist/Real.cpp.o.d -o CMakeFiles/plist.dir/Sources/plist/Real.cpp.o -c ../Sources/plist/Real.cpp
clang: error: argument unused during compilation: '-I /usr/include/libxml2'
clang: error: argument unused during compilation: '-I ../Headers'
clang: error: argument unused during compilation: '-I ../PrivateHeaders'
clang: error: argument unused during compilation: '-I ../ThirdParty/googletest/googletest/include'
[10/324] Building CXX object CMakeFiles/plist.dir/Sources/plist/String.cpp.o
FAILED: /usr/local/opt/ccache/libexec/c++   -Dplist_EXPORTS -I/usr/include/libxml2 -I../Headers -I../PrivateHeaders -I../ThirdParty/googletest/googletest/include -std=c++11 -Wall -Werror -fcolor-diagnostics -g -fPIC -MMD -MT CMakeFiles/plist.dir/Sources/plist/String.cpp.o -MF CMakeFiles/plist.dir/Sources/plist/String.cpp.o.d -o CMakeFiles/plist.dir/Sources/plist/String.cpp.o -c ../Sources/plist/String.cpp
clang: error: argument unused during compilation: '-I /usr/include/libxml2'
clang: error: argument unused during compilation: '-I ../Headers'
clang: error: argument unused during compilation: '-I ../PrivateHeaders'
clang: error: argument unused during compilation: '-I ../ThirdParty/googletest/googletest/include'
[10/324] Building CXX object CMakeFiles/plist.dir/Sources/plist/ISODate.cpp.o
FAILED: /usr/local/opt/ccache/libexec/c++   -Dplist_EXPORTS -I/usr/include/libxml2 -I../Headers -I../PrivateHeaders -I../ThirdParty/googletest/googletest/include -std=c++11 -Wall -Werror -fcolor-diagnostics -g -fPIC -MMD -MT CMakeFiles/plist.dir/Sources/plist/ISODate.cpp.o -MF CMakeFiles/plist.dir/Sources/plist/ISODate.cpp.o.d -o CMakeFiles/plist.dir/Sources/plist/ISODate.cpp.o -c ../Sources/plist/ISODate.cpp
clang: error: argument unused during compilation: '-I /usr/include/libxml2'
clang: error: argument unused during compilation: '-I ../Headers'
clang: error: argument unused during compilation: '-I ../PrivateHeaders'
clang: error: argument unused during compilation: '-I ../ThirdParty/googletest/googletest/include'
ninja: build stopped: subcommand failed.
make: *** [all] Error 1

Warnings are not stored in a file when I redirect the output

After typing this:
//xcbuild -workspace .xcworkspace -scheme > out

I have all the warnings in the console instead of in the out file

Have an error while compiling a test

Have tried xcbuild on our project:
//xcbuild -workspace .xcworkspace -scheme

and it failed due to compiling a test file:
CompileC /Users//Library/Developer/Xcode/DerivedData/-fsfipbxnikwukxglpreqafamnoql/Build/Intermediates/.build/Debug-iphoneos/ModelTests.build/Objects-normal/arm64/.o /.m normal arm64 objective-c com.apple.compilers.llvm.clang.1_0.compiler

with an error
/// /.m:9:9: fatal error: 'XCTest/XCTest.h' file not found

import <XCTest/XCTest.h>

Launching the standard xcodebuild just works:
xcodebuild -workspace .xcworkspace -scheme

I can send via an email the CompileC command strings for from the logs if it is necessary.

Handle read-only headers during build

CocoaPods has been setting all files in the sandbox to read-only permissions for a while. Xcode seems to automatically adjust permissions in its builtin-copy, but xcbuild does not. This leads to "Permission Denied" errors during any subsequent build of projects affected by this.

Example project: https://github.com/contentful/contentful.swift, run xcbuild -workspace Contentful.xcworkspace -scheme Contentful twice to see this problem.

build action output gets truncated in log

Example:

CompileC /Users/sam/Library/Developer/Xcode/DerivedData/ComicReader-cshmtlgsivejuxheiprlktsmcemx/Build/Intermediates/ComicReader.build/Debug-iphoneos/ComicReader.build/Objects-normal/armv7/main.o ComicReader/main.m normal armv7 objective-c com.apple.compilers.llvm.clang.1_0.compiler
    cd /Users/sam/Projects/ComicReader
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c -arch armv7 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -std=gnu99 -fobjc-arc -fmodules -fmodules-cache-path=/Users/sam/Library/Developer/Xcode/DerivedData/ModuleCache -fmodules-prune-interval=86400 -fmodules-prune-after=345600 -Wnon-modular-include-in-framework-module -Werror=non-modular-include-in-framework-module -Wno-trigraphs -fpascal-strings -O0 -Wno-missing-field-initializers -Wno-missing-prototypes -Werror=return-type -Wno-implicit-atomic-properties -Werror=deprecated-objc-isa-usage -Werror=objc-root-class -Wno-arc-repeated-u

The action is being truncated mid-write to the build log.

linux error: empty path for sdk manager

I'm trying to build an Xcode project on a Linux machine with xcbuild successfully installed.

This is the output I'm getting (xcbuild is located in the root directory of my machine):

$ ~/xcbuild/./build/xcbuild -project PROJECT.xcodeproj -scheme PROJECT
error: empty path for sdk manager
error: couldn't create SDK manager
error: couldn't create build environment

Implement -usage command line option

xcbuild has a -usage option to explain the usage of the tool. Right now, this option is unimplemented.

To implement this, change Driver.cpp in xcdriver to call into UsageAction::Run(). Then, create a UsageAction class and implement the Run() method to print out usage info.

Support for archiving

Archiving and Code Signing

impression.h not found?

It builds in Mac OS El Capitan but nor working under Yosemite:

../Libraries/libcar/Sources/Rendition.cpp:21:10: fatal error: 'compression.h' file not found
#include <compression.h>

Got this error when trying to build xcbuild

Relative Path

XCBuild is unable to parse project files that contain relative path without quote.
Also, there's no error indication of what is failing and where, making it hard to debug.

e.g.
FAILURE - path = ../Test/MyTestFile.m;
SUCCESS - path = "../Test/MyTestFile.m";

Error -
project.pbxproj is not parseable: Expected entry separator or array end; found something else

Missing inputencoding parameter for CopyStringsFile

When building this project with xcbuild using xcbuild -project Kraftstoff.xcodeproj -target Kraftstoff -sdk iphonesimulator build, the build fails with

CopyStringsFile …/Library/Developer/Xcode/DerivedData/Kraftstoff-gaytkgpjvvldifdisonxedsdxode/Build/Products/Release-iphonesimulator/kraftstoff.app/fr.lproj/Localizable.stringsdict fr.lproj/Localizable.stringsdict
    builtin-copyStrings --validate --outputencoding binary --outdir …/Library/Developer/Xcode/DerivedData/Kraftstoff-gaytkgpjvvldifdisonxedsdxode/Build/Products/Release-iphonesimulator/kraftstoff.app/fr.lproj -- fr.lproj/Localizable.stringsdict
error: fr.lproj/Localizable.stringsdict: strings key 'Imported %d car(s) with %d fuel event(s).' is not a string

** BUILD FAILED **

The same build succeeds with xcodebuild. The only difference I can spot is that xcodebuild adds the inputencoding parameter for the CopyStringsFile task:

CopyStringsFile build/Release-iphonesimulator/kraftstoff.app/fr.lproj/Localizable.stringsdict fr.lproj/Localizable.stringsdict
    export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
    builtin-copyStrings --validate --inputencoding utf-8 --outputencoding binary --outdir …/Kraftstoff/build/Release-iphonesimulator/kraftstoff.app/fr.lproj -- fr.lproj/Localizable.stringsdict

This error seems to only occur for stringsdict files, other .strings files are processed just fine.

facebookarchive / xcbuild Goto Github PK

xcbuild's Introduction

xcbuild

Why xcbuild?

xcbuild and other build tools

Building xcbuild

Requirements

All platforms

Linux

Ubuntu 18.04

All others

FreeBSD

FreeBSD 12.1

OpenBSD

OpenBSD 6.6

macOS

Windows

Instructions

All platforms

Linux and macOS:

FreeBSD and OpenBSD:

Windows (experimental):

Usage

Using Ninja (or llbuild)

Contributing

Thanks

xcbuild's People

Contributors

Stargazers

Watchers

Forkers

xcbuild's Issues

import <XCTest/XCTest.h>

Recommend Projects

Recommend Topics

Recommend Org