Apple

On Feb 18, 2016, at 2:49 PM, Jens Alfke wrote:

On Feb 18, 2016, at 11:37 AM, Alex Zavatone <email@hidden> wrote:

In the new app's Build Settings, we had to set up the Other Linker Flags to point to the proper directories where the linked libs were built.

You�re not just changing the Library Search Paths setting?

Thanks for checking that. While we were going through the process, I was instructed to change Other Linker Flags for Debug, Distribution and Release. We also changes Search Paths User Header Search Paths for the specific project that we were trying to get built.

I admit that your suggestion makes much more sense, but I was following instructions and simply entered paths to where the libs were relative from my build directory.

FYI, nothing was changed in our internal project that suddenly failed to build after getting the 3rd party source & linked libs to build from source.

Here's the case.

The 3rd party source has 4 xcode project files that create .a files that project B needs to link to. Project B's target app settings does not have these four .a files linked to the target at all. It appears that the paths to the .a files are only specified in the Other Linker Flags section of the build settings of project B's target app. They are not in the file navigator of project B.

In the four sections of the Build Phases section of project B none of these .a files are included anywhere at all.

I have no idea how this approach works and this is not how our internal projects are set up to link to external .a files.

Entering the .a file paths for the Other Linker Flags and a file path to the Header Search Paths within the Build Settings of the Target app of project B was how I was instructed to get this app built and running on the device this morning.

I don't understand how it works either. Actually, it can't work but that's another issue. Consider that email already written and sent.

Here's where the scary issue happens.

After closing this project and then opening our internal project from yesterday, I ended up seeing all sorts of build errors in our internal project. Nothing was changed in the internal project. It doesn't link to the 3rd party project or use any of its code.

All I did was change the Derived Data settings for Build Location to Legacy and the build errors started in our internal project.

When I changed the Derived Data settings for Build Location back to Unique, quit and restarted Xcode did the problems resolve themselves on a fresh build to the device.

That, I don't understand at all.

: /

Since I'm using the default Xcode Build Location settings of Unique (in a unique subfolder of Xcode's Derived Data location), this meant that the build directory for the .a files were nested deep down in some derived data folder with a folder name like "MyProduct-jdhksjdhvdjkcbkjcbdsvkdsvkdsjhdkjfhdsfjkdhsf" and of course each one was different for each of the .a files I was building.

That shouldn�t matter if you�re using the build variables like $(CONFIGURATION_BUILD_DIR).

Where would these variables be used in the build settings?

�Jens

References:
	>Xcode 7.1 changing the location of the derived data. (From: Alex Zavatone <email@hidden>)
	>Re: Xcode 7.1 changing the location of the derived data. (From: Jens Alfke <email@hidden>)