I am starting to work on this right away. I should note that the `--xcconfig-overrides` option isn't actually documented, but some people rely on it nonetheless. Therefore this should be fixed. And it should be done a bit better than the original so that any of the settings can be overridden.

The rewrite of the Xcode project generator kept the automatically emitted build settings at the same levels as the original version, in order to minimize semantic differences.

This means that `SWIFT_VERSION` (for example) is set at the target level, which still makes it unoverridable by the custom `.xcconfig` file. So part of this is to move some of these settings down to the project level.

So by "any of the build settings be overridden": there are some, such as the target name, that we would need something more than an `.xcconfig` file to override.

The simplest way in which to fix this is to associate the .xcconfig contents with each target, letting them override the project build settings (but still leaving them overridable by the target settings).

We can bring back the four separate .xcconfig files in a separate change if we want, though it should be noted that that in and of itself won't affect the layering and thus overridability of anything set at the target level.

This was fixed in #719

It looks like this is still an issue on master. On the swift-3.0 branch of this repo Reflejo/LambdaKit@cc78c3a you can run `make project` and then see that the generated project's SDKROOT is overridden by the project, and not by my custom xcconfig.

Ok, thanks. I'll take a look.

I suspect this is because some of the settings which LambdaKit is trying to override are set explicitly at the target level.

This is one benefit of the old model which tried to put everything into an xcconfig, it prevents us from making this mistake because we guaranteed the override xcconfig will win.

Yes, the direct reason why this fix doesn't help is that the just-added `SDKROOT` setting was added at the target level, not the project level, and thus not overridable either in the old or the current project generator.

Regarding the `.xcconfig` files: unfortunately we did not in fact guarantee that the `.xcconfig` would win. In practice many of the build settings were set at the target level (`SWIFT_VERSION` for example), and thus not overridable. I pulled some of them down to the project level, but others depend on the kind of target, and are therefore tricky to avoid putting at the target level.

Regarding the old vs current way of using `.xcconfig` files: the goal was to reduce the noise by having just the user's provided `.xcconfig` file and not a total of four in the case of a custom .xcconfig or three in the absence of one. It's very possible that it would be better to go back to generating `.xcconfig` files, but it's important to note that that alone wouldn't actually have affected this unless we can find a way to get the targets to not set build settings. So we may very well do that, but still need to move `SDKROOT` down to the project level.

I've filed https://bugs.swift.org/browse/SR-2904 since it's a separate issue (`SDKROOT` needs to be at the project level in order to be overridable).

Since https://bugs.swift.org/browse/SR-2904 was both a separate issue from this one, and since it has already been resolved, I'm moving this back to resolved since I don't believe there is anything more to fix here. If I am wrong, please set back to Open. Thanks.