Jason Merrill <ja...@redhat.com> writes:
> On 10/18/24 11:21 AM, Patrick Palka wrote:
>> On Fri, 18 Oct 2024, Jason Merrill wrote:
>>>
>>> Is it useful for std.cc to live in a subdirectory of c++23 as in this
>>> patch, or
>>> should it be in c++23 itself? Or elsewhere?
>> IIUC the src/ subdirectory is for stuff that gets compiled into the
>> .so
>> which isn't the case here.
>
> Sure, though I thought that might change once we consider it ABI-stable.
>
>> And if we want to support the std module in
>> C++20 mode as an extension, a c++23 subdirectory might not be ideal either.
>
> My impression has been that the subdirectories are just for organization?
>
>> Maybe libstdc++-v3/modules/ then?
>
> Let's see what Jonathan thinks.
>
> On 10/18/24 12:04 PM, Maciej Cencora wrote:
>> On Fri, 18 Oct 2024, Jason Merrill wrote:
>>> stdc++.h also doesn't include the eternally deprecated <strstream>. There
>>> are some other deprecated facilities that I notice are included: <codecvt>
>>> and float_denorm_style, at least. It would be nice for L{E,}WG to clarify
>>> whether module std is intended to include interfaces that were deprecated in
>>> C++23, since ancient code isn't going to be relying on module std.
>> Per P2465r3 Standard Library Modules std and std.compat:
>>> Are deprecated features provided by the Standard Library modules?
>>> Yes. This is implied by the normative wording.
>
> Ah, thanks.
>
>> While doing some light testing, one thing that immediately popped up is that
>> we need to export __normal_iterator related operators from __gnu_cxx
>> namespace.
>> Otherwise it is impossible to even use std::vector in range-based for loops.
>
> Ah, good catch.
>
>> But I think a better solution (than exporting such impl details) is to make
>> these operators hidden friends.
>
> That sounds right to me, and mechanically duplicating the declarations
> as friends seems to work (as attached).
>
>> Another thing - P2465r3 mentions only lerp, byte and related ops as
>> special w.r.t skipping export from global namespace in std.compat,
>> but for some reason Microsoft's impl treats 3-arg hypot as special
>> as well.
>
> Curious. By not declaring it at all when building the module? I don't
> want to mess with that if the standard doesn't require it.
>
> On 10/18/24 12:35 PM, Iain Sandoe wrote:
>>> Currently this installs the sources under $(pkgdata), i.e.
>>> /usr/share/libstdc++/modules. It could also make sense to install them
>>> under $(gxx_include_dir), i.e. /usr/include/c++/15/modules. And/or the
>>> subdirectory could be "miu" (module interface unit) instead of "modules".
>
>> I’d think that $(gxx_include_dir)/modules would be a good place, since that
>> allows us to tie it to the GCC version in side-by-side installs. Presumably
>> that
>> might also simplify finding the relevant sources?
>
> With side-by-side installs presumably $(prefix) would be different
> between them as well or the libraries would also clash?
We support multiple GCC side-by-side through "slotting".
The configure arguments we use right now are:
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/15
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15
(and so on).
That is, --prefix is the same between them, but the rest is tweaked.
>
> But I'm certainly not opposed to putting them under the include dir,
> that had been my inclination for a while, and with my
> -fsearch-include-path patch would make a simple compile easier without
> needing to teach the driver to parse the json.
>
>> I guess it could be just “module”, but my vote would be for an obvious name
>> like that or “std-module”
>
> Indeed singular "module" would be more consistent with "include" and "lib".
>
> On 10/19/24 8:08 AM, Florian Weimer wrote:
>>> The build system can find this file with
>>> gcc -print-file-name=libstdc++.modules.json
>> Is it possible to use specs file to redirect this to a different
>> file
>> based on C++ compiler flags, should that become necessary?
>
> Well, the compiler looks up a -print-file-name argument on its library
> search path, which can be added to with -B. But this is really an
> initial interface pending something more stable.
>
> Jason
>
> [2. text/x-patch; 0001-libstdc-normal_iterator-friends.patch]...
