Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 941680 - flag-o-matic.eclass: add D flags
Summary: flag-o-matic.eclass: add D flags
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-10-17 07:15 UTC by Sam James
Modified: 2025-04-10 14:23 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sam James archtester Gentoo Infrastructure gentoo-dev Security 2024-10-17 07:15:20 UTC
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 :)
Comment 1 Andrei Horodniceanu 2024-10-17 10:00:10 UTC
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.
Comment 2 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2025-04-10 13:17:48 UTC
I'll add GDCFLAGS for now to all-flag-vars, I think, in flag-o-matic.eclass, and leave the rest for now?
Comment 3 Andrei Horodniceanu 2025-04-10 14:17:54 UTC
(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
Comment 4 Larry the Git Cow gentoo-dev 2025-04-10 14:23:32 UTC
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(-)