xref: /xnu-10063.101.15/osfmk/kern/kcdata.modulemap (revision 94d3b452840153a99b38a3a9659680b2a006908e)
1*94d3b452SApple OSS Distributions#ifdef XNU_KERNEL_PRIVATE
2*94d3b452SApple OSS Distributions// kern/kcdata.h gets its own top level module outside of the Darwin module
3*94d3b452SApple OSS Distributions// to support building libkdd (one of our alias projects). libkdd can’t use
4*94d3b452SApple OSS Distributions// <kern/kcdata.h> because it doesn’t produce that header itself, and so Xcode
5*94d3b452SApple OSS Distributions// would pick up the old one in the SDK rather than mapping to the new one in
6*94d3b452SApple OSS Distributions// SRCROOT. To get around that, libkdd uses <kcdata.h> to not match anything in
7*94d3b452SApple OSS Distributions// the SDK and fall back on the one in SRCROOT. So far so good, but libkdd needs
8*94d3b452SApple OSS Distributions// to avoid accidentally also picking up <kern/kcdata.h> via a module, or it
9*94d3b452SApple OSS Distributions// will run into all kinds of redeclaration sadness that the include guards
10*94d3b452SApple OSS Distributions// somehow don’t block. (Maybe because <kcdata.h> isn’t modular and
11*94d3b452SApple OSS Distributions// <kern/kcdata.h> is?) libkdd uses the Darwin module, and so <kern/kcdata.h>
12*94d3b452SApple OSS Distributions// needs its own top level module that sits on top of Darwin.
13*94d3b452SApple OSS Distributions#endif
14*94d3b452SApple OSS Distributionsmodule kcdata [system] {
15*94d3b452SApple OSS Distributions  header "kern/kcdata.h"
16*94d3b452SApple OSS Distributions  export *
17*94d3b452SApple OSS Distributions}
18