Date: Thu, 13 Oct 2022 14:04:03 -0700
On Thu, Oct 13, 2022 at 12:21 PM Iain Sandoe via SG15 <sg15_at_[hidden]>
wrote:
> Hi Ben,
>
> > On 13 Oct 2022, at 18:40, Ben Boeckel <ben.boeckel_at_[hidden]> wrote:
> >
> > On Thu, Oct 13, 2022 at 09:41:27 +0100, Iain Sandoe via SG15 wrote:
> >> * AFAICT, the build system can figure that a source depends on a
> >> specific header, but it is also not able to determine if that header
> >> is an “importable” one (except for the sub-set that are pre-defined to
> >> be). Which means that we probably require that the user’s project
> >> defines which headers are importable. That disconnects metadata from
> >> the sources which is undesirable, if not a recipe for bugs.
> >
> > FWIW, the plan in CMake is to require metadata. If a header is not known
> > to be importable by CMake, no scanning of it will be performed, no
> > BMI-generating command will be in the graph, and therefore `import
> > <some-header>;` will fail to be resolved at build time (without compiler
> > magic going behind CMake's back, but that's just asking for ODR problems
> > if you ask me) because CMake won't know to add it via the "module map"
> > provided to compilation.
>
> As of the current implementation, there is no intention that “standard C++”
> modules perform any such compiler magic (although C++ “clang modules”
> are free to, of course).
>
> If such magic happens for the “standard" case, please file a PR.
>
> A build system could choose to consume meta-data (like modulemap files)
> from
> the source tree, of course.
>
> —
>
> I get Gaby’s assertion that ‘importable' is a property of use; however
> that does
> cascade to properties of generation.
>
> “import <some-header>;” is a statement by the user that the header should
> be
> available as a HU.
>
> That means it should be buildable as such (non-buildable then becomes the
> most
> trivial test for ‘importability’).
>
> I suppose that also means that a build system could take ‘import’ as an
> assertion
> of importability and then generate the relevant build commands (also
> allowing for
> include translation if the header is elsewhere “#include <>”’d).
>
I think this is what any build system that supports it should do. It's only
a problem for build systems that don't support dynamic task creation.
- Michael Spencer
>
> Not lobbying for any of this … I do consider my original question as
> answered.
>
> Iain
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
wrote:
> Hi Ben,
>
> > On 13 Oct 2022, at 18:40, Ben Boeckel <ben.boeckel_at_[hidden]> wrote:
> >
> > On Thu, Oct 13, 2022 at 09:41:27 +0100, Iain Sandoe via SG15 wrote:
> >> * AFAICT, the build system can figure that a source depends on a
> >> specific header, but it is also not able to determine if that header
> >> is an “importable” one (except for the sub-set that are pre-defined to
> >> be). Which means that we probably require that the user’s project
> >> defines which headers are importable. That disconnects metadata from
> >> the sources which is undesirable, if not a recipe for bugs.
> >
> > FWIW, the plan in CMake is to require metadata. If a header is not known
> > to be importable by CMake, no scanning of it will be performed, no
> > BMI-generating command will be in the graph, and therefore `import
> > <some-header>;` will fail to be resolved at build time (without compiler
> > magic going behind CMake's back, but that's just asking for ODR problems
> > if you ask me) because CMake won't know to add it via the "module map"
> > provided to compilation.
>
> As of the current implementation, there is no intention that “standard C++”
> modules perform any such compiler magic (although C++ “clang modules”
> are free to, of course).
>
> If such magic happens for the “standard" case, please file a PR.
>
> A build system could choose to consume meta-data (like modulemap files)
> from
> the source tree, of course.
>
> —
>
> I get Gaby’s assertion that ‘importable' is a property of use; however
> that does
> cascade to properties of generation.
>
> “import <some-header>;” is a statement by the user that the header should
> be
> available as a HU.
>
> That means it should be buildable as such (non-buildable then becomes the
> most
> trivial test for ‘importability’).
>
> I suppose that also means that a build system could take ‘import’ as an
> assertion
> of importability and then generate the relevant build commands (also
> allowing for
> include translation if the header is elsewhere “#include <>”’d).
>
I think this is what any build system that supports it should do. It's only
a problem for build systems that don't support dynamic task creation.
- Michael Spencer
>
> Not lobbying for any of this … I do consider my original question as
> answered.
>
> Iain
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
Received on 2022-10-13 21:04:18