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