Em qua., 25 de mai. de 2022 às 01:19, Nicolai Josuttis via Ext
<ext_at_[hidden]> escreveu:
> However, their code is not necessarily only used within projects that use a build system.
> It is a little piece of functionality useful in all kinds of programs (a key attribute of header files today).

This comes up even regardless of the requirement to have a build
system or not. Any transition to modules will very likely require
mixing usage via headers and usage via named modules in the same
program.

> They want to avoid double-written code or scripts to transform code form one format to another (header files to module or vice versa)
> And they really do not want to deliver/provide two different files of C++ code for the same functionality.
> Which results in the following question:
> What is the best approach / trick / hack to provide single-source code that can be used as both header file and module?
> Or should customers in situations like this not replace header files by something that supports modules at all?

My understanding, and I'd like some confirmation, is that you can
export a redeclaration from the global module fragment into the named
module. So you'd end up with something like

mylibrary/component.h
```
namespace mylibrary {
  class Component { ...
  };
}
```

mylibrary/component.ixx
```
module;
#include "mylibrary_component.h"
export module mylibrary.component;
namespace mylibrary {
  export class Component;
}
```

That way a codebase that wants to start using `import
mylibrary.component` while some of the source files still say
`#include <mylibrary/component.h>` would have a reasonable transition.

daniel