xref: /xnu-10063.121.3/osfmk/kern/kern_debug.modulemap (revision 2c2f96dc2b9a4408a43d3150ae9c105355ca3daa)

// It would've been nice to define this module in kern_private.modulemap,
// but that results in a compiler error. Maybe clang only supports sourcing
// multiple submodules from the same module map, but top level modules
// require their own?

// kern/debug.h gets its own top level module because it includes
// <kern/kcdata.h>, which gets its own top level module outside of the
// Darwin module to support building libkdd (one of our alias projects).
// libkdd can’t use <kern/kcdata.h> because it doesn’t produce that header
// itself, and so Xcode would pick up the old one in the SDK rather than
// mapping to the new one in SRCROOT. To get around that, libkdd uses
// <kcdata.h> to not match anything in the SDK and fall back on the one in
// SRCROOT. So far so good, but libkdd needs to avoid accidentally also
// picking up <kern/kcdata.h> via a module, or it will run into all kinds
// of redeclaration sadness that the include guards somehow don’t block.
// (Maybe because <kcdata.h> isn’t modular and <kern/kcdata.h> is?) libkdd
// uses the Darwin module, and so <kern/kcdata.h> needs its own top level
// module that sits on top of Darwin. libkdd uses the DarwinPrivate module
// too, and so that can't transitively include <kern/kcdata.h> for the
// reasons above.
module kern_debug [system] {
  header "kern/debug.h"
  export *
}