Caio/modules

[caiowakamatsu]

This PR is for finish the work @MilanBorovy started with #1290 to get C++ 20 modules working with EnTT.

I will rebase it against wip due to the STL injection changes causing a massive merge conflict.

---

Original PR text

• Make EnTT consumable as C++ module
• Added ENTT_MODULE CMake option enabling EnTT compilation as C++
• Added ENTT_USER_CONFIG CMake option to be able to specify C++ config defines

I've [@MilanBorovy] noticed that similar pull rq is already ongoing but seems to be dead for a few months.

Instead of exporting symbols in separate files, export macros are used (similar to how fmt does it).

By setting ENTT_MODULE CMake option to ON the EnTT::EnTT target becomes module library allowing EnTT to be consumed as import entt;.

Another option ENTT_USER_CONFIG is added to CMake. It can be used to configure entt as on can't simply #define all configurations inside source with modules.

Usage example:

entt_config.hpp

#define ENTT_ID_TYPE std::uint64_t
#define ENTT_USE_ATOMIC

CMakeLists.txt

...
set(ENTT_MODULE ON)
cmake_path(APPEND PROJECT_SOURCE_DIR user_config.hpp OUTPUT_VARIABLE ENTT_USER_CONFIG)

add_subdirectory(entt)

...

target_link_libraries(exe PUBLIC EnTT::EnTT)

Some explanation of this would be nice to put in wiki, unfortunately I [@MilanBorovy] can't pull request changes to wiki AFAIK.

[caiowakamatsu]

In favor of keeping this PR well scoped, I think an attempt to reconcile STL injection + modules should not be made here. Instead a separate PR should be done for that functionality.

[skypjack]

In favor of keeping this PR well scoped, I think an attempt to reconcile STL injection + modules should not be made here. Instead a separate PR should be done for that functionality.

That's fair. We still need to fix the conflicts though, and thanks for pointing this to wip. 🙏
My idea was to cut a release by the end of the month, but I'm fine with doing it in July if we want to include this one.

[caiowakamatsu]

@skypjack

My idea was to cut a release by the end of the month, but I'm fine with doing it in July if we want to include this one.

I don't think this is going to be able to be release-able in the next week in all likelihood. I've fixed a lot of the merge conflicts, but now there's a lot of compiler errors. I think getting this done by July may be realistic. But it's up to you if you want to hold off on the release for it :). I am ok with this either way

[caiowakamatsu]

@alexpanter @JonasGilg

Pinging you two to let you know that this branch should be stable / usable now for modules, since you guys showed interested in #1290.

I have tested it on my machine with GCC 16.1.1 / CMake 4.4.

[JonasGilg]

@alexpanter @JonasGilg

Pinging you two to let you know that this branch should be stable / usable now for modules, since you guys showed interested in #1290.

I have tested it on my machine with GCC 16.1.1 / CMake 4.4.

Thank you very much. Unfortunately I reverted the use of modules in my project, since there were too many bugs in MSVC with VS2022. I will visit this again when I can upgrade to VS2026.

[skypjack]

I've fixed a lot of the merge conflicts, but now there's a lot of compiler errors. I think getting this done by July may be realistic. But it's up to you if you want to hold off on the release for it :). I am ok with this either way

Not a big deal. Let's see how it goes. I started a run on the CI to know where we are. 👍