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