---------- Forwarded message ---------
From: Hassan Sajjad <hassan.sajjad069@gmail.com>
Date: Wed, Aug 2, 2023, 13:52
Subject: Re: [SG15] A Different Approach To Compiling C++
To: Ben Boeckel <ben.boeckel@kitware.com>

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@kitware.com> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15