C++ module interface

[msqr1]

I see your project using C++23, it doesn't have a C++ module support yet, and I could provide one using https://github.com/msqr1/importizer ? I would be happy to do this if you want!

[stephenberry]

I'd love to get a branch working with module support. Would it work across GCC, MSVC, and Clang? If you want to try and submit a pull request I'd love to see how much progress can be made. I do expect we might need to submit some bug reports because this is a large and complex project.

FYI, right now some of the Glaze tests do not build with the latest MSVC due to a recent compiler bug they introduced in 17.2. You can see #1448. We're pending the release of a fix.

[arturbac]

It can easy be done with better quality by hand than any auto converter to work with clang and gcc with CMake. C++ part is easy to do so. msvc AFIK does not have fully working modules at this time. CMake 3.31 works ok with modules.
Worst is there is no support for code completion in various ide for imported modules so I am sceptic for using modules at production in large project and lose all ide code completion support. I makes sense to use modules for ex release build but this is not a case I would optimise for myself, rather I would expect optimising development for which it will not yet work in IDE.

such case works ok on clang

shared lib
my_library.cxx

module ;
#include <string>

export module my_library;

export void do_something();

export template<typename T>
struct MyTemplate
  {
  T value;
  };

export struct MyStruct
  {
  int data;
  std::string str;  
  };

my_library.cpp

module;

#include <print>

module my_library;

void do_something() { std::print("Doing something!\n"); }

add_library(my_library SHARED)


target_sources(
  my_library
  PRIVATE src/my_library.cpp
  PUBLIC FILE_SET my_module_interface TYPE CXX_MODULES FILES
         "$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include/my_library.cxx>"
)

set_target_properties(
  my_library
  PROPERTIES CXX_STANDARD 23
             CXX_STANDARD_REQUIRED YES
             CXX_EXTENSIONS OFF
             CXX_SCAN_FOR_MODULES YES)

and using of module

import my_library;

int main()
  {
  do_something();

  MyTemplate<int> temp{42};

  MyStruct struct_ex{123, ""};

  return 0;
  }

cmake_minimum_required(VERSION 3.31)
project(my_project CXX)

set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
set(CMAKE_CXX_SCAN_FOR_MODULES ON)


add_subdirectory(my_library)

add_executable(my_executable src/main.cpp)
target_link_libraries(my_executable PRIVATE my_library)

install(TARGETS my_executable RUNTIME DESTINATION bin)
install(TARGETS my_library LIBRARY DESTINATION lib)

[arturbac]

More complicated it becomes in cmake configuration to maintain backward compatibility and option either to declare interface header only library or module library
example, I am experimenting with simple_enum

option(SIMPLE_ENUM_ENABLE_MODULE "Export c++ module" ON)
if( SIMPLE_ENUM_ENABLE_MODULE)
  add_library(simple_enum)
  target_sources(
      simple_enum
      PRIVATE FILE_SET HEADERS BASE_DIRS
              $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
      PUBLIC FILE_SET CXX_MODULES FILES
             "$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/module/simple_enum.cxx>"
    )
  set_target_properties(
    simple_enum
    PROPERTIES CXX_STANDARD 23
               CXX_STANDARD_REQUIRED YES
               CXX_EXTENSIONS OFF
               CXX_SCAN_FOR_MODULES YES)
else()
  add_library(simple_enum INTERFACE)
  target_sources(
    simple_enum
    INTERFACE FILE_SET
              HEADERS
              BASE_DIRS
              $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
              $<INSTALL_INTERFACE:include>)

  target_compile_features(simple_enum INTERFACE cxx_std_23)
endif()
if(SIMPLE_ENUM_OPT_IN_STATIC_ASSERTS)
  target_compile_definitions(simple_enum INTERFACE SIMPLE_ENUM_OPT_IN_STATIC_ASSERTS=1)
endif()

[arturbac]

BTW It is not about 'converting' into modules but to add optional module support , so additional c++ files declaring exports that can be ignored with normal pure include interface
EDIT:
And it is not about adding export at the top of includes and export everything including detail namespace, when someone does that it misses the point of using modules to export only public interface.
For example I add file exporting selected elements of simple_enum only, skipping all private type and data.

module;
#include <simple_enum/simple_enum.hpp>
#include <simple_enum/enum_index.hpp>
#include <simple_enum/enum_cast.hpp>
#include <simple_enum/generic_error_category.hpp>
#include <simple_enum/generic_error_category_impl.hpp>
#include <simple_enum/ranges_views.hpp>
#include <simple_enum/std_format.hpp>

export module simple_enum;

export namespace simple_enum
  {
using simple_enum::v0_8::enum_concept;
using simple_enum::v0_8::bounded_enum;

using simple_enum::v0_8::adl_info;
using simple_enum::v0_8::info;
using simple_enum::v0_8::enum_name;
using simple_enum::v0_8::enum_name_t;

using simple_enum::v0_8::enum_index_error;
using simple_enum::v0_8::enum_index_t;
using simple_enum::v0_8::enum_index;
using simple_enum::v0_8::consteval_enum_index;

using simple_enum::v0_8::enum_cast_error;
using simple_enum::v0_8::enum_cast_t;
using simple_enum::v0_8::enum_cast;
[..]
  }  // namespace simple_enum

[msqr1]

Don't worry, importizer aims to reduce much trivial work only, of course we still have to do some fixing and cleaning up ourselves, it's not as smart as a human :(.
The selling point is that the tool can do this kind of modularization for backward compatibility, optionally switching to modules with a single macro definition: https://github.com/msqr1/importizer/blob/main/Example.md#transitional-compilation-example . So you can still keep literally everything as-is.

In addition, it is not wrapping the header interface to export things, it is literally going to modularize it into a hybrid interface, supporting the global module migration.

But yeah, I do agree that linting is a bit annoying right now.

[arturbac]

IMHO mixing module and non module code with conditional macro definitions is low quality code hard to maintain and at the end difficult to read.

EDIT:
From last talk about module support is to not create files with *m mdoule extensions, just pure normal cc, cpp, cxx because AFIR there are already some problems with support for that in compilers.

[arturbac]

Btw for modules support You need to have 3.28

cmake_minimum_required(VERSION 3.28..3.31)

[msqr1]

Or you can just modularize it completely and maintain both the header ones and the module one. That would be tiring and repeating lots of code, though IMHO. Or you can just wrap it, but that wouldn't help with the global module migration :(.

About maintainability, I find that aside from the section on top of the file, everything else is the same, isn't it? At the end of the day, let's try and see how Stephen feels about it.

Also, the tool provides many options, including toggling the output extension. See more in the setting section of the README.

[arturbac]

I will give You and idea if You are a dev of this tool and maybe interested in that ..

With cmake You can get targets and its sources etc..
With libclang You can use AST to examine parsed code.
IMHO valuable would be a tool generating module file exporting everything for specified namespace and including proper incldues for given target from ccmake and it sources as below

module;
// include deps required for exported type
export module my_name;
// scanned output of types, classes, functions, and variables.

That would be very valuable tool for ppl with large projects, because You would be able to understand the result and maintain it.

[arturbac]

In ideal world we would liek to just convert our projects into module versions , but we ca not and we will not be able to do so for a long time .. IMHO separate files with explicit content being exported is better to maintain that conditional macros everywhere in code ..

[arturbac]

Or you can just modularize it completely and maintain both the header ones and the module one.

This is not feasible to maintain and not rational double the possibility of introducing bugs.

[arturbac]

Btw the decision is in Stephan's hands, I have nothing to do with it except to advise.

[msqr1]

Yeah, I am also planning for that, not only modularizing, but also wrapping the header intetface into a module. Right now I have only modularization (because I want to help with the migration), so I didn't implement wrapping yet, but it is also a good option to have.

Although I feel like this is done by hand really easily, just do some #include, and a big export block, right? Actual modularizing is way harder, that's why I made the tool.

IMHO separate files with explicit content being exported is better to maintain that conditional macros everywhere in code

This is right, but the hybrid form doesn't have conditional macros everywhere. It's only in the top section, there is no more conditional macros down below.

Also, we shouldn't be discussing extension to importizer here, can you make an issue there and we'll continue?

[arturbac]

This is right, but the hybrid form doesn't have conditional macros everywhere. It's only in the top section, there is no more conditional macros down below.

What about 90% of most incldues content in detail namespaces ? export everything ?

[msqr1]

There is an EXPORT macro (like assert) that is defined to be export when modules are on, and nothing when it's off. This is done in a separate file (no pollution) that is included automatically, so you can just place the EXPORT before whatever you want and be done! It's just a minimal replacement for the export keyword. Don't worry, it will get just a bit dirty at the top and no more.

A lot of people are probably confused like you, so maybe I should add an FAQ section 😆.