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