Remove $DFLAGS build type (but keep supporting the $DFLAGS variable)

[the-horo]

While it is useful and expected that dub would honor the $DFLAGS variable, it should not drop all flags that it adds on its own.

The most egregious way this is manifesting is that:

• dub test - runs unittests (duh)
• DFLAGS= dub test - does not run a single test

This is because dub would treat the presence (even if empty) of $DFLAGS as flags to override the current buildType. This has been changed and now $DFLAGS simply are appended to the flags derived from the buildType. If users actually want to prevent dub from passing any special flags they can do so with dub test --build=plain

[github-actions]

✅ PR OK, no changes in deprecations or warnings

Total deprecations: 0

Total warnings: 0

Build statistics:

 statistics (-before, +after)
 executable size=5249272 bin/dub
-rough build time=59s
+rough build time=58s

Full build output

DUB version 1.40.0, built on Jun  7 2025
LDC - the LLVM D compiler (1.41.0):
  based on DMD v2.111.0 and LLVM 20.1.5
  built with LDC - the LLVM D compiler (1.41.0)
  Default target: x86_64-unknown-linux-gnu
  Host CPU: znver3
  http://dlang.org - http://wiki.dlang.org/LDC


  Registered Targets:
    aarch64     - AArch64 (little endian)
    aarch64_32  - AArch64 (little endian ILP32)
    aarch64_be  - AArch64 (big endian)
    amdgcn      - AMD GCN GPUs
    arm         - ARM
    arm64       - ARM64 (little endian)
    arm64_32    - ARM64 (little endian ILP32)
    armeb       - ARM (big endian)
    avr         - Atmel AVR Microcontroller
    bpf         - BPF (host endian)
    bpfeb       - BPF (big endian)
    bpfel       - BPF (little endian)
    hexagon     - Hexagon
    lanai       - Lanai
    loongarch32 - 32-bit LoongArch
    loongarch64 - 64-bit LoongArch
    mips        - MIPS (32-bit big endian)
    mips64      - MIPS (64-bit big endian)
    mips64el    - MIPS (64-bit little endian)
    mipsel      - MIPS (32-bit little endian)
    msp430      - MSP430 [experimental]
    nvptx       - NVIDIA PTX 32-bit
    nvptx64     - NVIDIA PTX 64-bit
    ppc32       - PowerPC 32
    ppc32le     - PowerPC 32 LE
    ppc64       - PowerPC 64
    ppc64le     - PowerPC 64 LE
    r600        - AMD GPUs HD2XXX-HD6XXX
    riscv32     - 32-bit RISC-V
    riscv64     - 64-bit RISC-V
    sparc       - Sparc
    sparcel     - Sparc LE
    sparcv9     - Sparc V9
    spirv       - SPIR-V Logical
    spirv32     - SPIR-V 32-bit
    spirv64     - SPIR-V 64-bit
    systemz     - SystemZ
    thumb       - Thumb
    thumbeb     - Thumb (big endian)
    ve          - VE
    wasm32      - WebAssembly 32-bit
    wasm64      - WebAssembly 64-bit
    x86         - 32-bit X86: Pentium-Pro and above
    x86-64      - 64-bit X86: EM64T and AMD64
    xcore       - XCore
    xtensa      - Xtensa 32
   Upgrading project in /home/runner/work/dub/dub/
    Starting Performing "release" build using /opt/hostedtoolcache/dc/ldc2-1.41.0/x64/ldc2-1.41.0-linux-x86_64/bin/ldc2 for x86_64.
    Building dub 1.39.0-rc.1+commit.74.ged1d0029: building configuration [application]
     Linking dub
STAT:statistics (-before, +after)
STAT:executable size=5249272 bin/dub
STAT:rough build time=58s

[Geod24]

It's something I've been thinking about for a while now. I agree we should do it. I'm currently in vacations abroad so have limited time to review this week, but feel free to ping me next week if you see no action.

[s-ludwig]

While I do agree that the usability of the current approach is lacking and doesn't really make sense in the case of dub test, I honestly don't think we can just remove it, because it is completely unclear how that affects existing build scripts, also considering that DUB itself sets the DFLAGS variable when executing (pre/post) build commands.

Maybe an alternative approach could work here, for example a command line argument (e.g. dub -dflags="-foo -bar")?

[the-horo]

I honestly don't think we can just remove it, because it is completely unclear how that affects existing build scripts

scripts:

• without DFLAGS stay the same
• with DFLAGS and --build=... stay the same
• with DFLAGS and without an explicit --build=...
  • dub test - was broken, is now fixed
  • dub build and dub run - now add -g -debug

This really don't seem like that big consequence compared to the fact that there is no way to safely pass flags to the compiler when scripting, which is a very common occurrence with gdc and gdmd that almost always need -Wno-error to get around deprecations and, half the time, need -allinst. I currently can only:

1. Set DFLAGS and modify all dub test invocations with dub test --build=unittest
2. (only for gdmd) write to /etc/dmd.conf and set DFLAGS there.

also considering that DUB itself sets the DFLAGS variable when executing (pre/post) build commands.

As in it lets it leak into the environment, but doesn't actually set $DFLAGS to be used in build commands. The behavior stays the same in this sense.

Note that this is another issue that should be fixed/specified. Currently dub lets DFLAGS be inherited when spawning other processes which has 2 weird interactions

1. During compilation, ldmd2 and gdmd use that variable and append it to their CLI, leading to flags being added twice: once by dub when generating the build and once when invoking the compiler
2. Like you said, pre/post build commands are also affected, which is weird because $DC -run which is used by a couple of projects would compile with DFLAGS in the case of ldmd2 and gdmd

Maybe an alternative approach could work here, for example a command line argument (e.g. dub -dflags="-foo -bar"

Nothing easy comes to mind but --dflags I would read as a switch that overwrites the DFLAGS environment variable, but it would still behave the same semantically. So:

DFLAGS=-foo dub --dflags=-bar
dub --dflags=-bar
DFLAGS=-bar dub

I would imagine do the same thing: compile with -bar

[s-ludwig]

with DFLAGS and --build=... stay the same

Okay, with this, I'd agree that the consequences are rather limited and I don't have objections then. I was under the impression that currently DFLAGS would be ignored when a specific build mode was passed (not sure whether that already got changed along the way?). My --dflags suggestion is then also moot, as it is then indeed just the same as DFLAGS.

which is a very common occurrence with gdc and gdmd that almost always need -Wno-error to get around deprecations

The default mode should always be to treat "deprecations" as non-fatal warnings and "warnings" as errors. Code that doesn't compile without actual "warnings" should specify "allowWarnings" as a build requirement instead of relying on DFLAGS, though, but I guess you are in a situation where you are compiling foreign code with a newer compiler?

As in it lets it leak into the environment, but doesn't actually set $DFLAGS to be used in build commands. The behavior stays the same in this sense.

What I meant is actually the non-environment DFLAGS variable defined by the build variable feature that is only available within the package recipe itself. But you are also right that it will pass on the DFLAGS variable from the parent environment, which is actually really messy, unfortunately. So it looks like we'll eventually have to introduce some kind of breakage here in order to streamline this.

[the-horo]

The default mode should always be to treat "deprecations" as non-fatal warnings and "warnings" as errors. Code that doesn't compile without actual "warnings" should specify "allowWarnings" as a build requirement instead of relying on DFLAGS, though, but I guess you are in a situation where you are compiling foreign code with a newer compiler?

This is the issue, gcc (and, by extension gdc) does not have the concept of deprecations. It only knows about warnings. if -Werror is passed to gdc or -w to gdmd then any warning, including depractions diagnostics, will cause the build to fail.

I understand that this was the initial intention, to treat warnings as errors but, given the current landscape where:

1. dmd and ldc2 basically never output warnings, only deprecations
2. gdc and gdmd fail to build by default with deprecations

It sounds reasonable to abandon the original idea and to allow warnings by default, for gcc and gdmd at least. Given the current dub architecture where gdmd is treated as dmd it would mean that dmd would also be exempt from -w and if that's how it's going to go it makes sense to drop -w from ldc2 as well.

All of this is unrelated to this PR though, so maybe the discussion should be continued in a separate issue.

but I guess you are in a situation where you are compiling foreign code with a newer compiler?

yes, I usually hit it when trying to build somebody else's dub project, either in CI or as a package for Gentoo, and the build almost always prints deprecations, leading to ugly hacks to coerce dub into building with gdc. Gentoo also has a policy for disabling -Werror by default so that is a factor as well