add module support

[elvisdukaj]

Description

Trying to make EnTT consumable as a module instead of header only library.

TODO:

• Define the new cmake target name
• Define how cmake is installing a module: what does need to be installed? Is the PCM file needed to be exported as well?
• EnTT is specializing some std components (std::tuple_element, std::tuple_size, std::uses_allocator, std::ranges::enable_borrowed_range, std::ranges::enable_view`). How to export it? If it was C++23 it would have been easier
• Define how this module is consumed via cmake.
• How to test and avoid code duplication?

[skypjack]

Does it make sense to have a different target?
I mean, I want to compile it as a module library or to import it as a header-only library.
I don't see why I should want both. In this case, why not use the same name? It would also reduce the boilerplate and duplication.

[elvisdukaj]

It's a good point, actually I'm not sure how the cmake side is. Works. But definitely it makes sense aim for a single target

[skypjack]

Not a problem. I can merge everything on a branch and fix it on my own eventually. 👍

[skypjack]

Do you know what the common approach is for other already existing projects, if any?
I'm not sure I like the inc file in the same dir of the code. On the other hand, modules are still such a wild beast that I don't really know what I like in general. 😅
Any other well known GH repo of which you are aware that also supports modules out there?

[zaucy]

https://arewemodulesyet.org/
There are only a handful of libraries that try to support cpp20 modules
fmt is probably one of the most popular ones and it supports it with some defines instead of a bunch of .inc files. Namely these:

• FMT_MODULE
• FMT_EXPORT
• FMT_BEGIN_EXPORT
• FMT_END_EXPORT

https://github.com/fmtlib/fmt/blob/master/include/fmt/args.h#L11-L15
https://github.com/fmtlib/fmt/blob/5f6fb96df1637c3b4a2a068ab03e156ed8c3ea39/src/fmt.cc#L98-L100

I looked into what the support looks like awhile ago so I thought I'd share.

[elvisdukaj]

I saw three main approaches for handling modules:

1. fmt, tgui, use macros to know it export and not export, avoiding code duplication
2. glm, magic_enum use a single "cppm" file which essentially exports everything.
3. CMake use the same trick I am using here for exporting the standard template library.

I choosed the 3rd approach only because I wasn't familiar enough with the internal source code of entt. I don't think it's the best.

My considerations:

• The 1st approach is avoiding duplications, and adding/removing something that is exported is easier because that's onlly one file to touch. The downside is that you need to clearly separate what you export or not, for instance the internal namespace maybe it's not intended to be exported.
• The 2nd and 3rd approach are pretty similar, with the difference that you stash all the exports in a single files instead of splitting them in the equivalent header. I find it easier to touch the corresponding moudle file instead of a global file where everything is exported. The main advantage is that you can selectively choose what to export and not. In mu example for instance all the internal namespace is not exposed.

I can try to implement the 1st approach as well for having a better comparison.

As a side note, I would avoid to create new file extensions for c++ modules like (.cppm) since doesn't make much sense in my opinion and not all compilers go along with different extensions.

[skypjack]

I can try to implement the 1st approach as well for having a better comparison.

I don't want to waste your time, it's not necessary to implement it for all symbols. However, it would help if you could provide a small example, yeah. Something like for a single subdir or such. Is it something you can do?

[elvisdukaj]

It sounds like a plan, this Friday I can work on it

[skypjack]

Do you mean meta_arg? It shouldn't be static, of course 😲 I'm fixing it right away on wip and soon on master. Good catch.