Date: Mon, 21 Jun 2021 11:37:04 -0400
On 21/06/2021 09.00, Poliakoff, David Zoeller via SG15 wrote:
> Do we have a CMake guru in the group
That would be Ben Boeckel.
> who can tell me “David, don’t worry, we’ve been planning for this?”
That's a better question 🙂.
On 18/06/2021 20.07, Daniel Ruoso via SG15 wrote:
> Headers are super messy from a language perspective, but are very much
> straightforward from a tooling perspective, particularly in POSIX systems,
> where they are uncontroversially mapped to files on disk with a well
> defined lookup order and standardized compiler arguments.
>
> Modules are much more straightforward from the language perspective, but
> they force the issue of package management, which has been an area with
> very little convergence in the past, and they force the issue because they
> are a lot more semantically complex for the build system.
>
> That is not a bad trade off, most other languages have successfully pushed
> all of that complexity to a standardized package manager.
To clarify, when you say "package manager", we are talking about
discovering availability and configuration, *not* actually installing on
the system, correct? IOW, pkg-config, not dpkg/rpm/etc.? (Yes, they can
overlap, but more to the point, we're talking about something that the
likes of dpkg/rpm can ship without needing to be fundamentally changed.)
> Do we have a CMake guru in the group
That would be Ben Boeckel.
> who can tell me “David, don’t worry, we’ve been planning for this?”
That's a better question 🙂.
On 18/06/2021 20.07, Daniel Ruoso via SG15 wrote:
> Headers are super messy from a language perspective, but are very much
> straightforward from a tooling perspective, particularly in POSIX systems,
> where they are uncontroversially mapped to files on disk with a well
> defined lookup order and standardized compiler arguments.
>
> Modules are much more straightforward from the language perspective, but
> they force the issue of package management, which has been an area with
> very little convergence in the past, and they force the issue because they
> are a lot more semantically complex for the build system.
>
> That is not a bad trade off, most other languages have successfully pushed
> all of that complexity to a standardized package manager.
To clarify, when you say "package manager", we are talking about
discovering availability and configuration, *not* actually installing on
the system, correct? IOW, pkg-config, not dpkg/rpm/etc.? (Yes, they can
overlap, but more to the point, we're talking about something that the
likes of dpkg/rpm can ship without needing to be fundamentally changed.)
-- Matthew
Received on 2021-06-21 10:37:07