Date: Sun, 10 Dec 2023 11:05:58 -0500
To agree with René (I believe), long term we would like some packaging
standards (CPS) to lay all of this out, including for standard libraries.
Though we probably shouldn't hold up support of 'import std;' on design and
sufficient adoption of packaging standards. Given that, in our previous ISO
C++ Tooling discussions, we identified link lines as the only real
commonality. We've been thinking tools should be able to discover metadata
about locations for modular interfaces and configurations for how to build
them, and those files would be located relative to the library binaries, so
the binary for libc++ in the cases Mark brings up.
We haven't seen specific proposals for specific schemas or specific
algorithms for locating these files relative to library files. That seems
like the next step to me.
One option would be to just use the existing CPS schema, or some variation
of it, and pick one or more relative deployment locations for it.
In terms for POSIX systems, I expect the compilation flags will be specific
to each binary, so a path under arch specific subdirs of lib and/or lib64
makes sense.
Though, again, long term we want to be discovering CPS files as the primary
interface for configuration build systems and the CPS files would point to
install locations for the libc++ binary, its headers, the std module,
compilation flags, etc.
Bret
On Sun, Dec 10, 2023, 10:19 René Ferdinand Rivera Morell via SG15 <
sg15_at_[hidden]> wrote:
> On Sun, Dec 10, 2023 at 7:11 AM Mark de Wever via SG15
> <sg15_at_[hidden]> wrote:
> >
> > The questions I have:
> >
> > Where should we install the module files (.*cppm and *.inc)?
> >
> > How can we provide build systems with the compiler flags and files needed
> > to build the modules? MSVC STL currently provides a module.json [3],
> > should we use that as a basis?
> >
> > Do we need to provide dependency information between the std.compat and
> > std module? MSVC STL does not have that information in their JSON, but
> > std.compat exports the std module.
>
> All those questions have relatively easy answers if the std modules
> got distributed through existing package managers.
>
> --
> -- René Ferdinand Rivera Morell
> -- Don't Assume Anything -- No Supone Nada
> -- Robot Dreams - http://robot-dreams.net
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
>
standards (CPS) to lay all of this out, including for standard libraries.
Though we probably shouldn't hold up support of 'import std;' on design and
sufficient adoption of packaging standards. Given that, in our previous ISO
C++ Tooling discussions, we identified link lines as the only real
commonality. We've been thinking tools should be able to discover metadata
about locations for modular interfaces and configurations for how to build
them, and those files would be located relative to the library binaries, so
the binary for libc++ in the cases Mark brings up.
We haven't seen specific proposals for specific schemas or specific
algorithms for locating these files relative to library files. That seems
like the next step to me.
One option would be to just use the existing CPS schema, or some variation
of it, and pick one or more relative deployment locations for it.
In terms for POSIX systems, I expect the compilation flags will be specific
to each binary, so a path under arch specific subdirs of lib and/or lib64
makes sense.
Though, again, long term we want to be discovering CPS files as the primary
interface for configuration build systems and the CPS files would point to
install locations for the libc++ binary, its headers, the std module,
compilation flags, etc.
Bret
On Sun, Dec 10, 2023, 10:19 René Ferdinand Rivera Morell via SG15 <
sg15_at_[hidden]> wrote:
> On Sun, Dec 10, 2023 at 7:11 AM Mark de Wever via SG15
> <sg15_at_[hidden]> wrote:
> >
> > The questions I have:
> >
> > Where should we install the module files (.*cppm and *.inc)?
> >
> > How can we provide build systems with the compiler flags and files needed
> > to build the modules? MSVC STL currently provides a module.json [3],
> > should we use that as a basis?
> >
> > Do we need to provide dependency information between the std.compat and
> > std module? MSVC STL does not have that information in their JSON, but
> > std.compat exports the std module.
>
> All those questions have relatively easy answers if the std modules
> got distributed through existing package managers.
>
> --
> -- René Ferdinand Rivera Morell
> -- Don't Assume Anything -- No Supone Nada
> -- Robot Dreams - http://robot-dreams.net
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
>
Received on 2023-12-10 16:06:08