.xcconfig not being used for prefix header


John Brownie
 

I have been working on changing a C/C++/Objective C app that uses the Nano library so that it uses the LLVM C++ Standard Library rather than the GNU version. After a fair bit of work in Xcode 9, I get it compiling there. However, I have a significant problem when I move to Xcode 10, in that the settings in the .xcconfig files (particularly the header search paths) are not being used when precompiling (or, it seems, compiling) the prefix header.

That is the basis of the problem, but there is another mystery which may be related. In the Nano project, the .xcconfig files are listed in the Levels view between the project and the target, whereas in the main project, they are between the macOS default and the project.

Since the problem manifests in Xcode 10.2.1 and not in Xcode 9.4, I assume that it is the "new build system" that is likely to be the culprit, but there doesn't seem to be enough documentation about it to be sure.

Anybody else have this sort of issue, or know of what I could tweak to get around this?

Thanks,
John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland


Sak Wathanasin
 



On 22 Jul 2019, at 07:05, John Brownie <john_brownie@...> wrote:

I move to Xcode 10, in that the settings in the .xcconfig files (particularly the header search paths)

We use .xconfig files and have moved from XC9 through to XC11 and I haven't seen issues with settings in xcconfigs not being honoured. However, the big change between the old & new build systems, and the thing that is probably causing your problem, is that "header maps" are off by default with the new build system (there is a setting to revert to the old build system in the XC prefs).

"Header maps" was a feature where XC allowed you to refer to an include file by name whatever its actual path, so you could have

#include "foo.h"

even though its path may have been ..../my-subdir/..../foo.h and whether or not you had ..../my-subdir/..../ in your header search paths.

In the Xcode 10 rel notes, Apple says

• The legacy header map that was generated when the Always Search User Paths (ALWAYS_SEARCH_USER_PATHS) setting was YES is not supported by the new build system. Instead, set ALWAYS_SEARCH_USER_PATHS to NO and migrate to using modern header include syntax. Add any needed header files that are in the project repository to the Xcode project to ensure they are available for use in #include (via the project wide header map). Use quote-style include ("example.h") for project headers, and reserve angle-bracket include (<example.h>) for system headers.

I had to do a bunch of work to fix this in our projects. 

1) set USE_HEADERMAP = NO and  ALWAYS_SEARCH_USER_PATHS = NO in our xcconfig to set the global defaults
2) go through each project and made sure they weren't over-riding these settings
3) fix any "header file not found" errors by adding appr search paths in the projects' build settings

NB USE_HEADERMAP is "NO" by default with new build system; explicitly setting it to "NO' makes it behave the same way with the old build system. If you don't need to switch back to XC9, you can leave this out, I guess.

Also if you want to pass header paths defined in your xcconfig or global project settings down to individual target settings, you need to have

$(inherited)

as one of the "paths" in the settings.

You may have gotten away with it with the old build system since it would magically find the header file as long as it was in the source tree somewhere.

Hope this helps

Sak Wathanasin
Network Analysis Limited           http://www.network-analysis.ltd.uk


John Brownie
 

Header maps doesn't appear to be the issue. It is the fact that no header search paths are specified for the prefix header, except for one target. Looking at the two targets in the same project, both have the header file search path set correctly, and at the same level, but one ignores it for prefix, while the other doesn't.

Not having dealt with setting up .xcconfig files in many years (and this was already set up in the app template), I don't know how to ensure that they are invoked for any given target. Can someone point me to some useful documentation?

John

Sak Wathanasin wrote on 22/7/19 13:11:



On 22 Jul 2019, at 07:05, John Brownie <john_brownie@...> wrote:

I move to Xcode 10, in that the settings in the .xcconfig files (particularly the header search paths)

We use .xconfig files and have moved from XC9 through to XC11 and I haven't seen issues with settings in xcconfigs not being honoured. However, the big change between the old & new build systems, and the thing that is probably causing your problem, is that "header maps" are off by default with the new build system (there is a setting to revert to the old build system in the XC prefs).

"Header maps" was a feature where XC allowed you to refer to an include file by name whatever its actual path, so you could have

#include "foo.h"

even though its path may have been ..../my-subdir/..../foo.h and whether or not you had ..../my-subdir/..../ in your header search paths.

In the Xcode 10 rel notes, Apple says

• The legacy header map that was generated when the Always Search User Paths (ALWAYS_SEARCH_USER_PATHS) setting was YES is not supported by the new build system. Instead, set ALWAYS_SEARCH_USER_PATHS to NO and migrate to using modern header include syntax. Add any needed header files that are in the project repository to the Xcode project to ensure they are available for use in #include (via the project wide header map). Use quote-style include ("example.h") for project headers, and reserve angle-bracket include (<example.h>) for system headers.

I had to do a bunch of work to fix this in our projects. 

1) set USE_HEADERMAP = NO and  ALWAYS_SEARCH_USER_PATHS = NO in our xcconfig to set the global defaults
2) go through each project and made sure they weren't over-riding these settings
3) fix any "header file not found" errors by adding appr search paths in the projects' build settings

NB USE_HEADERMAP is "NO" by default with new build system; explicitly setting it to "NO' makes it behave the same way with the old build system. If you don't need to switch back to XC9, you can leave this out, I guess.

Also if you want to pass header paths defined in your xcconfig or global project settings down to individual target settings, you need to have

$(inherited)

as one of the "paths" in the settings.

You may have gotten away with it with the old build system since it would magically find the header file as long as it was in the source tree somewhere.

Hope this helps

Sak Wathanasin
Network Analysis Limited           http://www.network-analysis.ltd.uk


--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland


John Brownie
 

I found the issue in the end. For some reason, the configuration in one project was set at the project level, while it was at the target level in the other. When it is set at target level, definitions aren't applied to the precompiled header. Fixing that got me a clean compile at last.

John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland


Alex Zavatone
 

Check your build settings for the location of your precompiled header.

On Jul 22, 2019, at 1:05 AM, John Brownie <john_brownie@sil.org> wrote:

I have been working on changing a C/C++/Objective C app that uses the Nano library so that it uses the LLVM C++ Standard Library rather than the GNU version. After a fair bit of work in Xcode 9, I get it compiling there. However, I have a significant problem when I move to Xcode 10, in that the settings in the .xcconfig files (particularly the header search paths) are not being used when precompiling (or, it seems, compiling) the prefix header.

That is the basis of the problem, but there is another mystery which may be related. In the Nano project, the .xcconfig files are listed in the Levels view between the project and the target, whereas in the main project, they are between the macOS default and the project.

Since the problem manifests in Xcode 10.2.1 and not in Xcode 9.4, I assume that it is the "new build system" that is likely to be the culprit, but there doesn't seem to be enough documentation about it to be sure.

Anybody else have this sort of issue, or know of what I could tweak to get around this?

Thanks,
John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland



Alex Zavatone
 

Oh, have you tried the Legacy Build System?

It is under your File menu in either Workspace Settings or Project Settings.

On Jul 22, 2019, at 1:05 AM, John Brownie <john_brownie@sil.org> wrote:

I have been working on changing a C/C++/Objective C app that uses the Nano library so that it uses the LLVM C++ Standard Library rather than the GNU version. After a fair bit of work in Xcode 9, I get it compiling there. However, I have a significant problem when I move to Xcode 10, in that the settings in the .xcconfig files (particularly the header search paths) are not being used when precompiling (or, it seems, compiling) the prefix header.

That is the basis of the problem, but there is another mystery which may be related. In the Nano project, the .xcconfig files are listed in the Levels view between the project and the target, whereas in the main project, they are between the macOS default and the project.

Since the problem manifests in Xcode 10.2.1 and not in Xcode 9.4, I assume that it is the "new build system" that is likely to be the culprit, but there doesn't seem to be enough documentation about it to be sure.

Anybody else have this sort of issue, or know of what I could tweak to get around this?

Thanks,
John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland



John Brownie
 

Just to be clear, everything is working again. I eventually found where to adjust how the .xcconfig files are put in the chain, and it's in the Project view, in the Info tab, under Configurations. I don't know if something got changed behind my back, but setting the desired configuration at the project rather than target level fixed things. Of course, that begs the question why precompiling the prefix header doesn't use the target settings...

John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland