Re: Sourceware mitigating and preventing the next xz-backdoor

Martin Uecker writes: > Do we really still need complex build systems such as autoconf? Are > there still so many different configurations with subtle differences > that every single feature needs to be tested individually by running > code at build time? We have taken the alternative approach

Re: GCC 12.1 Release Candidate available from gcc.gnu.org

Jakub Jelinek writes: > The first release candidate for GCC 12.1 is available [...] There is an unfixed bogus warning that is a regression in 12 and that I think will have a pretty wide effect (any code that assigns/appends a 1-char string literal to std::string):

Re: [modules] Preprocessing requires compiled header unit modules

Ben Boeckel writes: > If we need to know and have dependencies prepared before we can figure > out the dependencies for a TU, modules are unsolvable (without an active > build executor). If C++ implementations are really going to require > that, then [...] the following tools are all unsuitable

Re: [modules] Preprocessing requires compiled header unit modules

Iain Sandoe writes: > The standard has the concept of an “importable header” which is > implementation-defined. But it must contain all the C++ library headers: https://eel.is/c++draft/headers#4 > We could choose that only headers that are self-contained (i.e. unaffected > by external

Re: [modules] Preprocessing requires compiled header unit modules

Ben Boeckel writes: > On Thu, Apr 21, 2022 at 06:05:52 +0200, Boris Kolpackov wrote: > > > I don't think it is. A header unit (unlike a named module) may export > > macros which could affect further dependencies. Consider: > > > > import "header-unit.hpp&q

Re: [modules] Preprocessing requires compiled header unit modules

Ben Boeckel writes: > However, for header unit modules, it runs into a problem that imported > header units are required to be compiled and available in the mapper > while scanning for dependencies. > > Example code: > > ```c++ # use-header.cpp > module; > > import "header-unit.hpp"; > > int

Re: [24/32] module mapper

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

Re: Modules doc

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"):

Re: [00/32] C++ 20 Modules

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?

Re: [24/32] module mapper

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

Re: [04/32] cpp lexer

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-kolpackov/gcc-cxx-

Re: [00/32] C++ 20 Modules

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

Re: [00/32] C++ 20 Modules

bed 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/definitions.tex [2]

Re: [RFC] Adding Python as a possible language and it's usage

Paul Koning writes: > > On Jul 18, 2018, at 11:13 AM, Boris Kolpackov > > wrote: > > > > I wonder what will be the expected way to obtain a suitable version of > > Python if one is not available on the build machine? With awk I can > > build it from sour

Re: [RFC] Adding Python as a possible language and it's usage

On Tue, 2018-07-17 at 14:49 +0200, Martin Liška wrote: > My question is simple: can we starting using a scripting language like > Python and replace usage of the AWK scripts? I wonder what will be the expected way to obtain a suitable version of Python if one is not available on the build

Re: [PATCH v3] Ability to remap file names in __FILE__, etc (PR other/70268)

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

Re: [PATCH v3] Ability to remap file names in __FILE__, etc (PR other/70268)

Ximin Luo <infini...@pwned.gg> 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

Re: [PATCH v3] Ability to remap file names in __FILE__, etc (PR other/70268)

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

[COMMITTED] Add myself to MAINTAINERS (write after approval)

ChangeLog: 2018-01-18 Boris Kolpackov <bo...@codesynthesis.com> * MAINTAINERS (write after approval): Add myself. --- MAINTAINERS (revision 256843) +++ MAINTAINERS (working copy) @@ -454,6 +454,7 @@ Michael Koch <konque...@gmx.de> Ni

Re: [PATCH v4] Ability to remap file names in __FILE__, etc (PR other/70268)

bcpp/ChangeLog: 2018-01-13 Boris Kolpackov <bo...@codesynthesis.com> PR other/70268 * include/cpplib.h (cpp_callbacks::remap_filename): New callback. * libcpp/macro.c (_cpp_builtin_macro_text): Call remap_filename for __FILE__ and __BASE_FILE__. gcc/Ch

[PING 5] Ability to remap file names in __FILE__, etc (PR other/70268)

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

[PING 4] Ability to remap file names in __FILE__, etc (PR other/70268)

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:

[PING 3] Ability to remap file names in __FILE__, etc (PR other/70268)

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:

Re: [PATCH v3] Ability to remap file names in __FILE__, etc (PR other/70268)

ry 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 @code{__FILE__} and @code{__BASE_FILE__} macr

Re: [PATCH v2] Ability to remap file names in __FILE__, etc (PR other/70268)

n 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__ /* { dg-message "FILE-PREFIX" } */ > > +#pragma messag

[PING 2] Ability to remap file names in __FILE__, etc (PR other/70268)

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

[PING] Ability to remap file names in __FILE__, etc (PR other/70268)

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

Re: [PING] Plugin support on Windows/MinGW

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

Re: [PING] Plugin support on Windows/MinGW

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

[PING] Plugin support on Windows/MinGW

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

[PATCH] Ability to remap file names in __FILE__, etc (PR other/70268)

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 <bo...@codesynthesis.com> PR other

[PATCH] Plugin support on Windows/MinGW

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==windows_10-mingw_w64_gcc_7.2 Thanks, Boris config/ChangeLog: 2017-11-14 Boris Kolpackov <

[PATCH] Install cp/operators.def as part of plugin headers

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 <bo...@codesynthesis.com> * Make-l

[PATCH] Write dependency information (-M*) even if there are errors

(working copy) @@ -1,3 +1,8 @@ +2017-08-06 Boris Kolpackov <bo...@codesynthesis.com> + + * c-opts.c (c_common_finish): Write dependency information even if + there are errors. + 2017-07-14 David Malcolm <dmalc...@redhat.com> * c-common.c (try_to_locate_new_include_insertion_

Re: [PATCH] Write dependency information (-M*) even if there are errors

new revision included. Thanks, Boris Index: gcc/c-family/ChangeLog === --- gcc/c-family/ChangeLog (revision 250514) +++ gcc/c-family/ChangeLog (working copy) @@ -1,3 +1,8 @@ +2017-08-06 Boris Kolpackov <bo...@codesynthesis.com&

Re: [PATCH] Write dependency information (-M*) even if there are errors

Joseph Myers writes: > I suppose a question for the present proposal would be making sure any > dependencies generated in this case do not include dependencies on files > that don't exist (so #include "some-misspelling.h" doesn't create any sort > of dependency on

[PATCH] Write dependency information (-M*) even if there are errors

, Boris Index: gcc/c-family/ChangeLog === --- gcc/c-family/ChangeLog (revision 250514) +++ gcc/c-family/ChangeLog (working copy) @@ -1,3 +1,8 @@ +2017-08-06 Boris Kolpackov <bo...@codesynthesis.com> + + * c-opts.c (c_common_finish):

Separate preprocess and compile: some performance numbers

Hi, I have implemented the separate preprocess and compile setup in build2. For GCC it is using -fdirectives-only (thanks to everyone's suggestions in the earlier thread). I've also done some benchmarking: https://build2.org/article/preprocess-compile-performance.xhtml TL;DR for GCC:

[PATCH] Recognize '-' as special -MF argument (write to stdout)

Hi, Sometimes it is useful to generate pre-processed output to a file and the dependency information to stdout for further analysis/processing. For example: g++ -E -MD -fdirectives-only -o test.ii test.cxx This will generate the dependency information to test.d (as per the documentation). While

Re: Separate preprocess and compile: hack or feature?

Hi Nathan, Nathan Sidwell writes: > How c++ modules fit into a build system is currently an open question. > Richard Smith & I have talked about it, but with no firm conclusion. > However, I think that breaking out the preprocessor is not the right > answer. Handling modules is

Re: Separate preprocess and compile: hack or feature?

Hi Jakub, Jakub Jelinek writes: > Especially in recent GCC versions the amount of differences for warnings and > errors keeps dramatically increasing, with separate preprocessing simply > too much information is lost (macro contexts, lint style comments, exact > locations,

Separate preprocess and compile: hack or feature?

Hi, In the build system I am working on we are looking at always performing the preprocessing and then C/C++ compilation as two separate gcc/g++ invocations. The main reason is support for distributed compilation but see here[1] for other reasons. I realize that tools like ccache/distcc have

[ANN] build2 - C++ build toolchain

Hi, build2 is an open source, cross-platform toolchain for building and packaging C++ code. It includes a build system, package manager, and repository web interface. We've also started cppget.org, a public repository of open source C++ packages. This is the first alpha release and currently it

[ANN] ODB C++ ORM 2.4.0 Released

Hi, I am pleased to announce the release of ODB 2.4.0. ODB is an open source object-relational mapping (ORM) system for C++. It allows you to persist C++ objects to a relational database without having to deal with tables, columns, or SQL and without manually writing any of the mapping code. ODB

[ANN] CppCon 2014 program available

The CppCon 2014 Program is now available with talk titles, abstracts, and speakers: http://cppcon.org/conference-program/ The program contains over 100 one-hour sessions by over 70 speakers including plenary sessions by Scott Meyers and Herb Sutter, as well as the keynotes by C++ creator Bjarne

[ANN] CppCon 2014 Call for Submissions

Hi, CppCon is the annual, week-long face-to-face gathering for the entire C++ community. The conference is organized by the C++ community for the community and so we invite you to present. Have you learned something interesting about C++, maybe a new technique possible in C++11? Or perhaps you

[ANN] Registration for CppCon 2014 is Open

CppCon, The C++ Conference Opening Keynote by Bjarne Stroustrup September 7–12, 2014 Bellevue, Washington, USA Registration is now open for CppCon 2014 to be held September 7–12, 2014 at the Meydenbauer Center in Bellevue, Washington, USA. This year the conference starts with the keynote by

[ANN] Registration for C++Now 2014 is Open

Hi, Registration is now open for the eighth annual C++Now conference (formerly BoostCon) which will be held in Aspen, Colorado, USA, May 12th to 17th, 2014. C++Now is a general C++ conference for C++ experts and enthusiasts. It is not specific to any library/framework or compiler vendor and has

[ANN] C++Now 2014: 5 Days to Submissions Deadline

Hi, Only 5 days left before the submissions deadline for C++Now 2014! C++Now is a general C++ conference for C++ experts and enthusiasts. It is not specific to any library/framework or compiler vendor and has three tracks with presentations ranging from hands-on, practical tutorials to advanced

[ANN] ODB C++ ORM 2.3.0 released

I am pleased to announce the release of ODB 2.3.0. ODB is an open source object-relational mapping (ORM) system for C++. It allows you to persist C++ objects to a relational database without having to deal with tables, columns, or SQL and without manually writing any of the mapping code. ODB is

[ANN] ODB C++ ORM 2.2.0 released

Hi, I am pleased to announce the release of ODB 2.2.0. ODB is an open source object-relational mapping (ORM) system for C++. It allows you to persist C++ objects to a relational database without having to deal with tables, columns, or SQL and without manually writing any of the mapping code.

[ANN] C++Now 2013 submission deadline extended to January 5th

Just a quick note that the proposals deadline for the C++Now 2013 conference has been extended to January 5th: http://cppnow.org/2013-call-for-submissions/ C++Now is the largest general C++ conference, that is, it is not specific to any library/framework or compiler vendor. C++Now has three

Registration for C++Now 2013 is now open

The seventh annual C++Now Conference (formerly BoostCon) will be held at the Aspen Center for Physics in Aspen, Colorado, May 12th to 17th, 2013. We are thrilled to announce the second annual C++Now conference, the whole-language edition of BoostCon covering all the coolest topics in C++, said

Re: Traversing typedef hierarchy in C/C++ tree

Hi Dodji, Dodji Seketeli do...@seketeli.org writes: Boris Kolpackov bo...@codesynthesis.com a =C3=A9crit: template typename T struct wrap { typedef T w_s; }; typedef wrapmy_s_t::w_s w_s_t; Now if I traverse from w_s_t using DECL_ORIGINAL_TYPE I get: w_s_t-w_s-s

Report: using GCC plugin to implement ORM for C++

Hi, We have just released a C++ object-relational mapping (ORM) system, called ODB, that uses the new GCC plugin architecture. I thought I would report back to the GCC community on how the plugin part worked out. In a nutshell, the ODB compiler parses a C++ header with class declarations (and