Date: Tue, 1 Aug 2023 14:22:15 +0500
I emailed this mailing list following from this link
https://isocpp.org/std/submit-a-proposal. I floated the idea and if it gets
accepted, I will write a proposal. My proposal will be in the same category
as this paper P1689R5
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1689r5.html>.
>
> Regardless, I recommend you reach out to your fellow buildsystem
> communities,
> in case they are not represented in SG15.
I think they are represented in SG15. If not I will contact them.
> Can I also give you a piece of advice?
Sure.
> Phrase your discussion in terms of what
> the limitations of the language and/or the tooling are, not of your
> project.
I was unsure about it. Maybe there is a catch and I am missing something. I
will later on not mention my project except for the sake of an example.
> 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.
I should have said that no other build-system has even limited header-units
support in my email.
> 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.
I am not in this position. I can bring only the build-system perspective.
>From that solution 5 appears to be the most optimal. Maybe compiler-devs
can think of something different to alleviate this.
> That latter portion would be welcome in the std-discussion list.
I am unclear on what should be posted on this mailing list and what on the
std-discussion.
On Tue, Aug 1, 2023 at 11:39 AM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> 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.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel DCAI Cloud Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
https://isocpp.org/std/submit-a-proposal. I floated the idea and if it gets
accepted, I will write a proposal. My proposal will be in the same category
as this paper P1689R5
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1689r5.html>.
>
> Regardless, I recommend you reach out to your fellow buildsystem
> communities,
> in case they are not represented in SG15.
I think they are represented in SG15. If not I will contact them.
> Can I also give you a piece of advice?
Sure.
> Phrase your discussion in terms of what
> the limitations of the language and/or the tooling are, not of your
> project.
I was unsure about it. Maybe there is a catch and I am missing something. I
will later on not mention my project except for the sake of an example.
> 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.
I should have said that no other build-system has even limited header-units
support in my email.
> 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.
I am not in this position. I can bring only the build-system perspective.
>From that solution 5 appears to be the most optimal. Maybe compiler-devs
can think of something different to alleviate this.
> That latter portion would be welcome in the std-discussion list.
I am unclear on what should be posted on this mailing list and what on the
std-discussion.
On Tue, Aug 1, 2023 at 11:39 AM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> 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
> > 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
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2023-08-01 09:22:29