Since 6ef120e9895172dd7b2c6a1c9f5b14ef56c75ea7, toolchain.eclass attempts to print all relevant flags during build: ``` [...] * ADAFLAGS="" * CFLAGS="-march=native -pipe -fno-omit-frame-pointer -Warray-bounds=2 -fdiagnostics-explain-harder -Wno-array-bounds -Wno-array-bounds -Wno-array-bounds -Wno-array-bounds -O2" * CPPFLAGS="" * CXXFLAGS="-march=native -pipe -fno-omit-frame-pointer -Warray-bounds=2 -fdiagnostics-explain-harder -Wno-array-bounds -Wno-array-bounds -Wno-array-bounds -Wno-array-bounds -O2" * CCASFLAGS="" * FFLAGS="-march=native -pipe -fno-omit-frame-pointer -Warray-bounds=2 -fdiagnostics-explain-harder -O2" * FCFLAGS="-march=native -pipe -fno-omit-frame-pointer -Warray-bounds=2 -fdiagnostics-explain-harder -O2" * LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs" * Testing sys-devel/gcc:15 for Ada ... * Testing sys-devel/gcc:15 for D ... [...] ``` This doesn't include any sort of flags for D. What variables should we include, if any? GDCFLAGS? DFLAGS? DCFLAGS? Some LDFLAGS variant? I have no idea :)
Yeah, I saw this when doing changes to toolchain.eclass and I thought about it a little. I think we should only include GDCFLAGS as they are: 1. The only variable used by gcc/d/Make-lang.in 2. Possible to have been specified in a user's make.conf ::dlang also uses GDCFLAGS as the user variable for specifying flags when compiling D source code with gdc and it does recommend setting its value in make.conf hence the possibility of a user having a custom value for that. DFLAGS is the current de-facto variable for specifying flags for the D compiler, regardless of variant, and it is respected by build systems such as dub and meson but it's not used by gcc nor by ::dlang so I don't see any value caring about it. dmd, ldmd2, and, gdmd, do pick up that value from the environment and append it to the command line for what it's worth, with the exception of dmd having a broken implementation so, in practice, only ldmd2 and gdmd respect it. DCFLAGS is, I think, DFLAGS's ancestor before standardization and it is used by gtkd's makefile and it's also used by ::dlang to specify the flags for the current D compiler (the one in ${DC}), mostly for historical reasons. LDFLAGS variables are a bit out of the scope of D projects as the community's default when compiling something is doing everything in one go so, if you want to pass flags to the linker you just put them in DFLAGS or any other variable for specifying flags to the compiler. gcc's build system doesn't seem to respect anything other than LDFLAGS too. meson uses, I believe, LDFLAGS and it converts them internally from gcc-syntax to d-compiler syntax. ::dlang does a similar thing, it uses the LDFLAGS user variable and it converts it to something understood by the specified D compiler and it provides DLANG_LDFLAGS to ebuilds. So, only printing LDFLAGS seems like the appropriate solution. Since gcc is the only D related package in ::gentoo I think flag-o-matic should only be interested in flags that are relevant to it. ::dlang does need functions like append-dflags and filter-dflags but, given that the eclass has: - DMDFLAGS - LDCFLAGS - GDCFLAGS - DCFLAGS - $(dlang_get_dmdw_dcflags) - DLANG_LDFLAGS and it needs to handle both single and multi build and it has to deal with build systems without a configure step I would rather not introduce anything related to all of this in ::gentoo until I find an implementation that I'm satisfied with.
I'll add GDCFLAGS for now to all-flag-vars, I think, in flag-o-matic.eclass, and leave the rest for now?
(In reply to Sam James from comment #2) > I'll add GDCFLAGS for now to all-flag-vars, I think, in flag-o-matic.eclass, > and leave the rest for now? +1
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=15a1fcd97f44599319b17b8ef0ddc7137838200c commit 15a1fcd97f44599319b17b8ef0ddc7137838200c Author: Sam James <sam@gentoo.org> AuthorDate: 2025-04-10 14:22:06 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-04-10 14:22:54 +0000 flag-o-matic.eclass: add GDCFLAGS to all-flag-vars This means e.g. toolchain.eclass can conveniently print it, but it also enables a bunch of functions for GDCFLAGS. Bug: https://bugs.gentoo.org/941680 Acked-by: Andrei Horodniceanu <a.horodniceanu@proton.me> Signed-off-by: Sam James <sam@gentoo.org> eclass/flag-o-matic.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)