Nathan Sidwell writes:
> These are needed as they also serve to inform the mapper of a dependency
> edge.
Ok, that makes sense (and thanks for making it optional via a flag).
One thing that is still missing in this area is the dependency on
stdc-predef.h. In other words, we now can get everyth
Marek Polacek writes:
> > +Only emit the module CMI, inhibiting any object file.
>
> Maybe say here that CMI is Compiled Module Interface.
FYI, SG15 (WG21 study group on tooling) seems to have settled
on BMI ("built module interface"):
https://github.com/cplusplus/modules-ecosystem-tr/blob/mas
Nathan Sidwell writes:
> It is not a complete implementation. The major missing pieces are: [...]
Would now be a good time to start reporting bugs in bugzilla so that
things don't fall through the cracks? Is so, would it make sense to
add the "c++ modules" component to bugzilla?
I've noticed the following issues with the module mapper in the
-fdirectives-only mode:
1. When partially preprocessing the module interface unit, the mapper
receives the MODULE-EXPORT request that's unnecessary (BMI is not
written):
g++ ... -x c++ -E -fdirectives-only -o hello.gcm.ii h
always get set when entering it? Again,
> comment at the very least.
FWIW, I remember wrestling with that login in my branch, here are the
changes to directives-only.c (in particular, see the "Handle import
as pseudo-directive (P1703R0)" commit):
https://github.com/boris-kolpacko
Nathan Sidwell writes:
> The repo is providing a mechanism by which two processes can synchronize
> on a fixed location in the file system that is not /. You need such a
> capability as the file system is the bulk transfer mechanism.
>
> The alternatives are to always use absolute paths, or r
lso described in this[3]
WG21 paper). AFAIK, these extensions haven't yet been considered
for merging into c++-modules.
[1] BTW, SG15 seems to have settled on the BMI (built module
interface) term instead of CMI:
https://github.com/cplusplus/modules-ecosystem-tr/blob/master/defin
Ximin Luo writes:
> -I to an absolute path is not that common for system / distro-built
> stuff.
Ok, thanks for clarifying.
> In the cases that it occurs, indeed it could and should be fixed
> by the package buildsystem, e.g. by stripping a prefix when they
> add -I flags to CFLAGS. But that's
Ximin Luo writes:
> Boris Kolpackov:
>
> > This does feel like we are trying to fix the issue in the wrong place.
> > Also, won't such broken packages normally store all options (including
> > -I) rather than just CFLAGS? And if the answer is no, then perhaps you
&g
Ximin Luo writes:
> Higher-level build scripts sometimes like to save CFLAGS etc into the build
> output, making the overall build output unreproducible even if GCC is playing
> nicely. Rather than add logic to strip -f{file,debug,macro,...}-prefix-map,
> into all possible higher-level program
ChangeLog:
2018-01-18 Boris Kolpackov
* MAINTAINERS (write after approval): Add myself.
--- MAINTAINERS (revision 256843)
+++ MAINTAINERS (working copy)
@@ -454,6 +454,7 @@
Michael Koch
Nicolas Koenig
Kaz Kojima
semantics in the presence of '=' is a broken build, so this is
probably ok (but if not, let me know and I will revert this change).
I've also added this rationale to add_prefix_map() and a note in the
ChangeLog.
[1] https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01278.htm
Hi,
Looks like this is the last chance for this patch to make GCC 8
so I would like to ping it one last time:
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01451.html
It has been reviewed (with thanks) by David Malcolm[1] and
Martin Sebor[2]. Their concerns are addressed in the latest
revision o
Hi,
I would like to again ping this patch:
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01451.html
It has been reviewed (with thanks) by David Malcolm[1] and
Martin Sebor[2]. Their concerns are addressed in the latest
revision of the patch:
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00544.h
Hi,
I would like to again ping this patch:
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01451.html
It has been reviewed (with thanks) by David Malcolm[1] and
Martin Sebor[2]. Their concerns are addressed in the latest
revision of the patch:
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00544.h
ry old, or (2)
> the current working directory is old while preprocessing some
> files. To make it 100% clear which is meant, I would find it
> more accurate if it were phrased like this instead:
>
> When preprocessing files residing in directory @file{@var{old}},
> expand the
u document this in the .texi)
It's not really a special case (an empty prefix is a prefix of any path)
and is not very useful in practice. Are you sure it's a good idea to have
this noise seeing that I will have to do it for all three options?
> > +#pragma message __FILE__
Hi,
I would like to again ping this patch:
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01451.html
While the patch touches a few places, it is mostly reshuffling,
generalizing, and fixing existing code. It also includes tests
for the new functionality. Seeing that there is interest[1] in
reprod
Hi,
I would like to ping this patch:
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01451.html
While the patch touches quite a few places, it is mostly reshuffling
and generalizing existing code. It also includes tests for the new
functionality. Seeing that there is a lot of interest[1] in reprod
JonY <10wa...@gmail.com> writes:
> Libtool shouldn't matter since it is not used to build those, [...]
We don't know which build system the plugin author will use to build
the plugin. We can, however, reasonably expect that it will be able
to produce a shared library with the platform-standard ex
JonY <10wa...@gmail.com> writes:
> Is there a problem with using .so for internal libraries instead of
> "dll"...
I think not but I haven't tested it. The problem with using .so instead
of .dll is that producing this non-standard extension may not be easy
or possible depending on the build system
Hi,
I would like to ping this patch:
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01040.html
The changes are fairly conservative: they do not touch much of the
existing module implementation and plugin support on MinGW is disabled
by default (there are also fixes for a couple of bugs as a bonus
offers a significantly different implementation though I used the
original patch as a reference to make sure I've covered all the areas
(e.g., __builtin_FILE()).
Copyright assignment is on file.
libcpp/ChangeLog:
2017-11-17 Boris Kolpackov
PR other/70268
* include/cpp
brary extensions).
Copyright assignment is on file.
[1] https://codesynthesis.com/products/odb/
[2] https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gcc
[3] https://stage.build2.org/?builds=&cf=windows_10-mingw_w64_gcc_7.2
Thanks,
Boris
config/ChangeLog:
2017-11-14 Boris
Hi,
cp/cp-tree.h now includes operators.def which means it has to be installed
as part of the plugin headers. The below patch addresses this (copyright
assignment is on file).
Thanks,
Boris
gcc/cp/ChangeLog:
2017-11-07 Boris Kolpackov
* Make-lang.in (CP_PLUGIN_HEADERS): Add
Ping.
On 13 Aug 2017 Boris Kolpackov writes:
Hi,
I've been instructed to resend this patch from the gcc mailing list:
Currently GCC does not write extracted header dependency information
if there are errors. However, this can be useful when dealing with
outdated generated headers that tr
ng header in
the dependency output, as requested.
P.S. I have the paperwork necessary to contribute on file with FSF.
Thanks,
Boris
Index: gcc/c-family/ChangeLog
===
--- gcc/c-family/ChangeLog (revision 250514)
+++ gcc/c-family/Ch
27 matches
Mail list logo
