Prefix header for C targets

Is there any plan to support prefix header when building C targets? This is a pretty standard feature, and would be useful in many situations. I think this can be achieved by using unsafeFlags, but such packages can't be used as a dependency, even for local development.

What about adding it as CSetting.prefixHeader()?

1 Like

I think it should be fine to add since it doesn't break the hermetic build model but IDK if there are other gotchas with prefix headers. Perhaps @Douglas_Gregor knows?

Not sure I agree, we could end up with a lot of build setting APIs this way. I think we need to be careful and evaluate which ones are important enough to add.

1 Like

It would also be helpful to know what the desired use case is.

"Prefix header" could mean a couple different things:

  • A file included textually at the beginning of each source file
  • A file that is precompiled, and that precompiled header is added at the beginning of each compilation

The first is just adding a compilation flag to the build, but less efficient. The second is more efficient, but more work because the build system needs to register a separate action to precompile the file and then add that as an input to subsequent compile actions.

Someone from Apple can correct me if I'm wrong, but the use of precompiled headers by default also seems to have fallen to the wayside in deference to modules—old Xcodes used to use precompiled headers to speed up imports of common frameworks, but modules are a cleaner representation of that. Modules don't replace all uses of prefix headers, but if the desired use case is "I want to avoid repeating a lot of common inclusions", then supporting modules is probably the better answer there.

It often occurs that you need to include a set of common definitions that are supposed to be known to all files while building a library. For instance, I'd like to test against TARGET_OS_IPHONE everywhere in implementation files. The only alternative without a prefix header is to manually #import <TargetConditionals.h> in every single file, which is both error prone (test can silently fail if forgotten), and tedious (repetitive code). Like, adding #import "common_prefix.h" to tens or hundreds of .c files.

About the replacement with a module, I agree that, with caching, they efficiently replace precompiled headers when they are used as a speed optimization. But my use case is not about speed, and I don't see how modules could help solve the issue here (can you give an example of what you have in mind?).

Now it is not that I'd absolutely want a specific setting. I'd be fine with generic "safe" flags that would let me use this package as a dependency to other packages, as there's nothing unsafe about importing a file that resides in the package source tree. That being said, if it's very often used, a dedicated setting could well make sense.

1 Like

+1 for the common definition case of injecting #import "x.h"

Terms of Service

Privacy Policy

Cookie Policy