Xmake also supports C++20 modules and header-units, and supports
gcc/clang/msvc as well.

It takes precedence over the compiler's built-in scanning module
dependencies, such as msvc's `/scanDependencies`. For compilers that don't
yet support it, xmake will fall back to using its own implementation of
module dependency scanning.

In addition, Xmake has experimental support for module distribution and
module package management.

Some examples: xmake/tests/projects/c++/modules
<https://github.com/xmake-io/xmake/tree/master/tests/projects/c%2B%2B/modules>

A complete project using xmake/c++ modules:
https://github.com/alibaba/async_simple/blob/main/xmake.lua

Hassan Sajjad via SG15 <sg15_at_[hidden]> 于2023年8月2日周三 22:27写道：

>
> ---------- Forwarded message ---------
> From: Hassan Sajjad <hassan.sajjad069_at_[hidden]>
> Date: Wed, Aug 2, 2023, 13:52
> Subject: Re: [SG15] A Different Approach To Compiling C++
> To: Ben Boeckel <ben.boeckel_at_[hidden]>
>
>
> New build systems are always interesting to watch
>
>
> Thank you.
>
> How do you propose to handle generated sources? Those by an external
>> tool can be solved by doing all generation before scanning, but if the
>> tool that generates the sources is in the source tree too, you need to
>> have multiple scanning phases.
>
>
> Sorry, I doubt that I understood you correctly. But I would like to
> mention that the module file is a SMFile, that inherits from BTarget, that
> can have dependencies in round1 (the round in which scanning is done). So,
> you can specify a dependency BTarget. In BTarget::updateBTarget, you can
> generate the module smfile. I haven't tested this, however. Will like to
> see a use case before adding an example and a test for it.
>
> Other interesting cases (that you may or may not care about supporting):
>> - duplicate modules (by name) that are in executables and never in the
>> same program
>> - per-target (or, harder, per-source) flags that require distinct module
>> compilations (header and/or named)
>> - handling modules that come from external projects (and might not have
>> stable lists of files that participate)
>
>
> Sorry, I did not understand the third point. The first two are supported.
> https://github.com/HassanSajjad-302/Example11
>
> As for your core issue:
>> Alas, I think this will cause some ache as `<version>` is likely to fall
>> into this use case. I don't know that (effectively) banning feature
>> macros in the importing region of the source is going to fly long-term.
>> Nevermind what one might want from a `config.h`-alike that contains
>> macro definitions describing the state of the build environment and what
>> APIs exist.
>
>
> Very interested in seeing how this will not be a limitation in other build
> systems. For now, solution 5 appears to be the only optimal solution.
> Others are either nonoptimal or have annoyances. I will implement the
> conclusion we reach.
>
> On Tue, Aug 1, 2023 at 10:37 PM Ben Boeckel <ben.boeckel_at_[hidden]>
> wrote:
>
>> On Sat, Jul 29, 2023 at 17:28:03 +0500, Hassan Sajjad via SG15 wrote:
>> > I will like to showcase my build-system HMake
>> > https://github.com/HassanSajjad-302/HMake.
>> >
>> > It has C++20 modules and header-units support. It also supports drop-in
>> > header-files to header-units replacement.
>> >
>> > With it, with MSVC I compiled an SFML example with C++ 20 header-units.
>> > https://github.com/HassanSajjad-302/SFML
>>
>> New build systems are always interesting to watch. It's a rough out at
>> sea here though ;) .
>>
>> > HMake however has a flaw and there is no easy solution for it. To fix
>> this,
>> > I will like to propose a new way to compile source files.
>> >
>> https://github.com/HassanSajjad-302/HMake/wiki/HMake-Flaw-And-Its-Possible-Fixes
>> >
>> > I am very confident that the adoption of this will result in flawless
>> > module and header-unit support in HMake which will translate to a very
>> good
>> > user experience while converting their code base to C++20 modules.
>> >
>> > Please share your thoughts.
>>
>> I see this in that wiki page:
>>
>> HMake works by first scanning all source-files, during which it
>> establishes dependencies between them, then it topologically sorts
>> and then builds them.
>>
>> How do you propose to handle generated sources? Those by an external
>> tool can be solved by doing all generation before scanning, but if the
>> tool that generates the sources is in the source tree too, you need to
>> have multiple scanning phases.
>>
>> Other interesting cases (that you may or may not care about supporting):
>>
>> - duplicate modules (by name) that are in executables and never in the
>> same program
>> - per-target (or, harder, per-source) flags that require distinct module
>> compilations (header and/or named)
>> - handling modules that come from external projects (and might not have
>> stable lists of files that participate)
>>
>> As for your core issue:
>>
>> The consequence is that the macros imported from other header-units
>> cannot be used to dictate header-files inclusion. This is the
>> limitation of the only compiler supported for modules in HMake at
>> the moment, MSVC. During the scan process, it does not take into
>> account the header-units. It just ignores them. link But even if it
>> gets fixed in the compiler, it won't be supported in the HMake.
>>
>> Alas, I think this will cause some ache as `<version>` is likely to fall
>> into this use case. I don't know that (effectively) banning feature
>> macros in the importing region of the source is going to fly long-term.
>> Nevermind what one might want from a `config.h`-alike that contains
>> macro definitions describing the state of the build environment and what
>> APIs exist.
>>
>> --Ben
>>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>

-- 
_______________________________________________
Ruki Wang
https://xmake.io
https://github.com/waruqi