Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 7 Jul 2025 07:22:56 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        ivy@freebsd.org, dev-commits-src-main@freebsd.org
Cc:        Dimitry Andric <dim@FreeBSD.org>, Kyle Evans <kevans@FreeBSD.org>
Subject:   RE: git: d3c06bed2c16 - main - clang: install clang-scan-deps (enable generation of std*.cppm and such too?)
Message-ID:  <FD5A67C4-7118-43A6-927B-9463D29C123D@yahoo.com>
References:  <FD5A67C4-7118-43A6-927B-9463D29C123D.ref@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Lexi Winter <ivy_at_FreeBSD.org> wrote on
Date: Sun, 06 Jul 2025 21:02:58 UTC :

> The branch main has been updated by ivy:
>=20
> URL: =
https://cgit.FreeBSD.org/src/commit/?id=3Dd3c06bed2c16b434dd49958dee5de8c5=
5ad00b85
>=20
> commit d3c06bed2c16b434dd49958dee5de8c55ad00b85
> Author: Lexi Winter <ivy@FreeBSD.org>
> AuthorDate: 2025-07-06 20:42:58 +0000
> Commit: Lexi Winter <ivy@FreeBSD.org>
> CommitDate: 2025-07-06 21:02:52 +0000
>=20
> clang: install clang-scan-deps
>=20
> clang-scan-deps is used to generate dependency information from C++20
> modules according to proposed standard ISO/IEC WG21 P1689R5[0]. It is
> required by common build tools (e.g., CMake) to build C++ sources
> that use modules.
>=20
> Since this is a core build tool, install it by default, not gated
> behind MK_CLANG_EXTRAS.
>=20
> [0] =
https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2022/p1689r5.html
>=20
> MFC after: 3 days
> Reviewed by: kevans, dim
> Approved by: kevans (mentor)
> Requested by: jbo
> Differential Revision: https://reviews.freebsd.org/D51044


Would it be reasonable to also enable generation/installation of,
say (picking one example set of placements for illustration):

/usr/lib/libc++.module.json (a guess about where it goes)

/usr/include/c++/v1/std.cppm
/usr/include/c++/v1/v1/std.compat.cppm

to enable use of "import std;" and "import std.compat;" in c++23
baesd projects (and clang's c++20 as it turns out)? There likely
would also be:

/usr/include/c++/v1/std/*.inc
/usr/include/c++/v1/v1/std.compat/*.inc

An alternate might set of placements might be:

/usr/lib/libc++.module.json

/usr/share/libc++/v1/std.cppm
/usr/share/libc++/v1/std.compat.cppm

/usr/share/libc++/v1/std/*.inc
/usr/share/libc++/v1/v1/std.compat/*.inc

Both styles would allow for alternate paths involving, say
something like:

/usr/local/llvm20/lib/libc++.module.json

/usr/local/llvm20/include/c++/v1/std*
vs.:
/usr/local/share/llvm20/libc++/v1/std*

(where the * may expand to more path components).

Precompiling, say, a std module with the compiler options
matching a project could look like:

# clang++ -std=3Dc++23 -precompile -o std.pcm \
/usr/local/llvm20/include/c++/v1/std.cppm

vs.

# clang++ -std=3Dc++23 -precompile -o std.pcm \
/usr/local/share/llvm20/libc++/v1/std.cppm

then, say:

# clang++ -O3 -std=3Dc++23 -fmodule-file=3Dstd.pcm -o teststd =
teststd.cpp



(My understanding is that clang++ 19.1.7 fixed the problem
it previously had with finding libc++.module.json when it
is part of the installed materials. But I'm not familiar
with the details.)


=3D=3D=3D
Mark Millard
marklmi at yahoo.com




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FD5A67C4-7118-43A6-927B-9463D29C123D>