I take my words back. Your build-system also has support for C++20
header-units. In C++20 modules / header-units support, my build-system
still has a point as it supports drop-in replacement of header-files with
header-units. Your build-system, however, supports 3,4 other features which
give yours plus points.

I have best wishes for your project.

Best,
Hassan Sajjad

On Wed, Aug 2, 2023 at 7:38 PM Ruki Wang <waruqi_at_[hidden]> wrote:

> 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
>