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