Current `-Mmodules` output is based on [P1602R0](wg21.link/p1602r0), which
speaks about a set of Makefile rules that can handle modules, with the help of
module mappers and a modified GNU Make.
The proposal came out in 2019, and the output of those rules was implemented
at GCC in 2020. However, so
I read a few mails from the autoconf thread. I'll try to read all now. However,
a maybe-off-topic-but-could-be-on-topic question: what exactly is the state of
Autotools now? The whole Autotools build system seems to be on a very slow
release cycle. They seem to lack enough contributors/maintainers
On Tuesday, March 4th, 2025 at 18:04, Ben Boeckel via Gcc
wrote:
> On Tue, Mar 04, 2025 at 07:53:51 +, vspefs wrote:
>
> > By the way, what's stop us from having compiler options like
> > `g++ -Rgcm.cache -Rsomewhere/else/gcm.cache` to specify CMI repo path, like
> > `-I`
> > for include p
By the way, what's stop us from having compiler options like
`g++ -Rgcm.cache -Rsomewhere/else/gcm.cache` to specify CMI repo path, like `-I`
for include paths? It could be useful for projects with complex folder
structure, as build tools like Make sometimes change current working directory,
and so
ia Gcc
wrote:
> On Thu, Feb 27, 2025 at 21:39 vspefs via Gcc gcc@gcc.gnu.org wrote:
>
> > Current `-Mmodules` output is based on P1602R0, which
> > speaks about a set of Makefile rules that can handle modules, with the
> > help of
> > module mappers and a modifi
On Sunday, March 2nd, 2025 at 02:13, Ben Boeckel via Gcc
wrote:
> On Sat, Mar 01, 2025 at 16:15:12 +, vspefs wrote:
>
> > I read a few mails from the autoconf thread. I'll try to read all now.
> > However,
> > a maybe-off-topic-but-could-be-on-topic question: what exactly is the state
> >
On Wednesday, March 5th, 2025 at 21:06, Nathaniel Shead via Gcc
wrote:
> Worth noting that GCC already provides a mapper that you can customise:
>
> $ g++ -fmodules -fmodule-mapper='|@g++-module-server -r path' -c m.cpp
>
> for an m.cpp that provides a module "M" will write to 'path/M.gcm'.
E
