How to create a library without headers?

user_11012105 0
Viewed 345

We have modules in C++20, can we completely remove #include in our code?

For example, we can write

import boost.asio;
...

Instead of

#include <boost/asio.hpp>
...

In the past we need these steps to install a library:

  • Compile all sources (.cpp) into objects (.o).
  • Package them into a library (.a or .so).
  • Install the headers into /usr/include.
  • Install the library files into /usr/lib.

In C++20, we may:

  • Compile all sources, but each source file may produce an object (.o) and a Compiled Module Interface (CMI). For gcc, they have .gcm suffixes.
  • Package the objects (.o) into a library (.a or .so).
  • Install the library files into /usr/lib.
  • Install the CMIs into some path.

But releasing your library with CMIs cause problems:

  • We don't have a special folder to place the CMIs (maybe /usr/include/c++-modules, I guess).
  • Different compilers produce different CMIs. It's terrible for developers to provide different versions of CMIs for their libraries.
  • What if we compile module A depending on module B, but using different compiling flags? A different flag may not catch your attention, but may cause potential bugs.

It's not a good way to replace headers with CMIs. So how can we completely remove headers from C++?

I'm not talking about the standard library, as modular c++ standard library is introduced in c++23.

c++-modules c++20 c++
1 Answers

Modules are not meant to be a binary distribution mechanism; you should expect to supply module interface files (i.e., the same files compiled to object files in your library, which are not header files) in a very header-like fashion and leave the CMI generation and caching to the client’s compiler and build tree (respectively). The build speed benefits may thus be realized by each client only after the first translation unit that uses a given module.

Other sharing mechanisms may very well come to appear in practice, but the important part here is that it’s not intrinsically more complicated or less compatible than existing build strategies.

user_85862270
Related