>
> Thanks for reaching out. I have gone through the thread and I am
> still a little confused probably because the approach is quite different
> from what we have been used to.
>

Thank you so much for commenting. Yes, it is a quite different approach.

   It seems that there are two aspects that you are proposing: a) the
> way the build system describes the build rules; b) how we can
> efficiently translate the build rules into action. IIUC in some
> languages (duck typing predominantly) they use the language itself to
> describe the rules, too.
>

I just wanted to let you know that I am not commenting on what language the
build-system should use. I am just proposing a new approach with the
potential of a good speed-up. I am only partially aware of the other
build-systems design, specifically the design around C++20 modules /
header-units. Because this is a different approach, non-trivial changes
might be needed in other build-systems to support it.

The second part is more interesting to me. AFAICT your approach
> inverts the build graph /somehow/. Is the aim to provide a "symbol
> registry" which upon of the symbol to compile the relevant subgraph? I'd
> appreciate if you could describe more verbosely (with examples maybe)
> how the process works.
>

My pleasures.

Please see the attached document. In it, I analyze how I plan to add
support for this in my build-system. I also provide an example. Based on
the analysis, I am confident in my ability to implement this within one
month if it's approved and a compiler with an API becomes available. While
I currently see no issues, I acknowledge the possibility of limitations and
potential errors. I am currently awaiting feedback from other stakeholders
before proceeding.

A slight correction in my above email. I mentioned that my build-system now
is limitation-free with the adoption of the new consensus. Well, it is for
a clean build. But there is a small bug for rebuild which will be fixed
soon.

Best,
Hassan Sajjad

On Tue, Aug 22, 2023 at 8:49 PM Vassil Vassilev <v.g.vassilev_at_[hidden]>
wrote:

> Hi Hassan,
>
> Thanks for reaching out. I have gone through the thread and I am
> still a little confused probably because the approach is quite different
> from what we have been used to.
>
> It seems that there are two aspects that you are proposing: a) the
> way the build system describes the build rules; b) how we can
> efficiently translate the build rules into action. IIUC in some
> languages (duck typing predominantly) they use the language itself to
> describe the rules, too.
>
> The second part is more interesting to me. AFAICT your approach
> inverts the build graph /somehow/. Is the aim to provide a "symbol
> registry" which upon of the symbol to compile the relevant subgraph? I'd
> appreciate if you could describe more verbosely (with examples maybe)
> how the process works.
>
> Best, Vassil
>
> On 7/29/23 3:28 PM, Hassan Sajjad via SG15 wrote:
> > Hi.
> >
> > 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
> >
> > 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.
> >
> > Best,
> > Hassan Sajjad
> >
> > _______________________________________________
> > SG15 mailing list
> > SG15_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
>
>