Date: Mon, 31 Jul 2023 23:39:25 -0700
On Monday, 31 July 2023 22:50:11 PDT Hassan Sajjad via Std-Proposals wrote:
> I think SG15 mailing is the ideal place for this conversation. As review
> from different backgrounds is needed including that from the
> other build-systems devs.
> I posted this on SG15 mailing 3 days ago. I received an email that my email
> will be either posted on the mailing or I will be informed about the
> decision. Neither was my email posted nor was I informed about the
> decision. Then 2 days ago I requested the SG15 mailing owner about the
> status of my email. I have not received a response yet. So, I posted it
> here.
3 days ago was Friday, so this time span covers a weekend. Please give people
more time -- usually a week is a reasonable time for reaction. It's also July
and a lot of people take either July or August off as vacations.
Still, std-proposals is the wrong place. Even if tooling was in -scope, it's
still the wrong list because you didn't make any proposals to the standard.
You're requesting feedback on your tool and maybe have a request for the
toolchain changes.
Regardless, I recommend you reach out to your fellow buildsystem communities,
in case they are not represented in SG15.
Can I also give you a piece of advice? Phrase your discussion in terms of what
the limitations of the language and/or the tooling are, not of your project.
When you wrote "HMake however has a flaw and there is no easy solution for it",
my first reaction was to wonder why I should care about a tool I had never
heard about. I bet I wasn't the only one.
Your argument, however, isn't that your tool has a flaw (implied: that it's
your fault), it's that any such tool would have a similar limitation and thus
it affects the entire ecosystem. Moreover, you should analyse whether such a
limitation is inherent in the C++ Modules standard language or if it is a
limitation of the implementations. I think you're saying it's the latter, but
I can't be sure. But even if it is, a discussion of whether any language
changes would also solve or alleviate the problem would be interesting.
That latter portion would be welcome in the std-discussion list.
> I think SG15 mailing is the ideal place for this conversation. As review
> from different backgrounds is needed including that from the
> other build-systems devs.
> I posted this on SG15 mailing 3 days ago. I received an email that my email
> will be either posted on the mailing or I will be informed about the
> decision. Neither was my email posted nor was I informed about the
> decision. Then 2 days ago I requested the SG15 mailing owner about the
> status of my email. I have not received a response yet. So, I posted it
> here.
3 days ago was Friday, so this time span covers a weekend. Please give people
more time -- usually a week is a reasonable time for reaction. It's also July
and a lot of people take either July or August off as vacations.
Still, std-proposals is the wrong place. Even if tooling was in -scope, it's
still the wrong list because you didn't make any proposals to the standard.
You're requesting feedback on your tool and maybe have a request for the
toolchain changes.
Regardless, I recommend you reach out to your fellow buildsystem communities,
in case they are not represented in SG15.
Can I also give you a piece of advice? Phrase your discussion in terms of what
the limitations of the language and/or the tooling are, not of your project.
When you wrote "HMake however has a flaw and there is no easy solution for it",
my first reaction was to wonder why I should care about a tool I had never
heard about. I bet I wasn't the only one.
Your argument, however, isn't that your tool has a flaw (implied: that it's
your fault), it's that any such tool would have a similar limitation and thus
it affects the entire ecosystem. Moreover, you should analyse whether such a
limitation is inherent in the C++ Modules standard language or if it is a
limitation of the implementations. I think you're saying it's the latter, but
I can't be sure. But even if it is, a discussion of whether any language
changes would also solve or alleviate the problem would be interesting.
That latter portion would be welcome in the std-discussion list.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2023-08-01 06:39:27