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
On Tue, Mar 04, 2025 at 01:09:33PM +, vspefs via Gcc wrote:
> 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 -Rsomewh
On Mon, Mar 3, 2025 at 23:53 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 paths? It could be useful for projects with complex folder
> structure, as build tools like
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
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 paths? It could be useful for projects with complex folder
> structure, as build t
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
Hi,
I'm Ben and implemented modules support in CMake, authored P1689 itself,
its support in GCC, and helped wrangle its support into clang and MSVC.
I encourage you to read this paper:
https://mathstuf.fedorapeople.org/fortran-modules/fortran-modules.html
which describes the strategy CMake
On Sat, Mar 01, 2025 at 20:01:21 +, vspefs wrote:
> Supporting C++ modules is easy, but I don't think "properly" is possible for
> any
> build system under current circumstances. Industrial consensus needed for many
> subjects:
I believe CMake is the furthest in this regard (though I haven't
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 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 of
> Autotools now? The whole Autotools build system seems to be on a very slow
>
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
GCC conjures up both .o file and .gcm file in one invocation when possible, too.
And yes, that can be managed well with grouped target - but a rule with grouped
target must have a recipe, which I think is a little beyond `gcc -M`'s scope.
Thanks for bringing up the pattern rule workaround, though.
On Fri, Feb 28, 2025 at 07:59:00 -0800, NightStrike via Gcc wrote:
> Could your approach simultaneously be used to have better dependency
> information for Fortran modules? I feel like there’s at least some overlap
> there.
P1689 is also intended to be suitable for Fortran (CMake uses it for its
F
On Fri, Feb 28, 2025 at 13:54:45 -0500, Paul Smith wrote:
> On Fri, 2025-02-28 at 19:26 +0100, Ben Boeckel via Gcc wrote:
> > > In POSIX make, including GNU Make, if a command doesn't modify the
> > > modification time of the target then that target is not considered
> > > updated, and other target
On Fri, 2025-02-28 at 19:26 +0100, Ben Boeckel via Gcc wrote:
> > In POSIX make, including GNU Make, if a command doesn't modify the
> > modification time of the target then that target is not considered
> > updated, and other targets which list it as a prerequisite are not
> > invoked:
>
> Hmm. M
On Fri, Feb 28, 2025 at 13:07:04 -0500, Paul Smith wrote:
> On Fri, 2025-02-28 at 18:05 +0100, Ben Boeckel via Gcc wrote:
> > Note that one thing that is missing is ninja's `restat = 1` feature.
> > This "restats" the output for the associated rule (probably spelled
> > `.RESTAT: output` in Make) a
On Fri, 2025-02-28 at 13:07 -0500, Paul Smith via Gcc wrote:
> ~$ touch three; make -f /tmp/x3.mk MKTWO=echo
Sorry this should be just "make MKTWO=echo"; my typo.
On Fri, 2025-02-28 at 18:05 +0100, Ben Boeckel via Gcc wrote:
> Note that one thing that is missing is ninja's `restat = 1` feature.
> This "restats" the output for the associated rule (probably spelled
> `.RESTAT: output` in Make) and skips running dependent rules if the
> output has not updated t
On Thu, Feb 27, 2025 at 21:39 vspefs via Gcc wrote:
> 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
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
20 matches
Mail list logo
