Add ability to specify frameworks to link against

[LunaTheFoxgirl]

This pull-request adds a new configuration variable called frameworks as an analogue to libs; which allows specifying which frameworks to link against.

Frameworks are semantically different from dylibs/shared objects, as such libs is not really able to provide this functionality.

The frameworks directive is ignored on non-darwin systems.

[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=61s
+executable size=5261560 bin/dub
+rough build time=59s

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.77.g396de0e8: building configuration [application]
     Linking dub
STAT:statistics (-before, +after)
STAT:executable size=5261560 bin/dub
STAT:rough build time=59s

[rikkimax]

I would suggest changing this to appleFrameworks instead.

Given that this is limited to Apple platforms anyway, it prevents us from using that directive for things that may be D-specific in the future. Which may be necessary for PhobosV3.

[LunaTheFoxgirl]

I would suggest changing this to appleFrameworks instead.

Given that this is limited to Apple platforms anyway, it prevents us from using that directive for things that may be D-specific in the future. Which may be necessary for PhobosV3.

Not limited to apple platforms; limited to ones that use mach-o, or which support mach-o.
Given changes happening in linux-land with stuff like darling, just calling it frameworks is more appropriate, imho.

[thewilsonator]

tests?

[LunaTheFoxgirl]

tests?

Added some rudementary tests into the existing unit tests for parsing; but I should probably also add a macOS specific test that tries to link to foundation or something.

[LunaTheFoxgirl]

Failed test is unrelated to the PR, fetchzip apparently had a stroke in that run

[LunaTheFoxgirl]

@thewilsonator added unit test passes; linking to Foundation.framework successfully.

[s-ludwig]

Looks good to me - definitely nice to have, also because it avoids duplicate framework arguments when multiple dependencies specify the same framework.

Should also be listed in https://github.com/dlang/dub-docs/blob/master/docs/dub-reference/build_settings.md

[the-horo]

@LunaTheFoxgirl is the frameworks test invoking the linker on osx? On my linux dub build simply builds a static library so there's no linking done if you specify a configuration without a target type.

[LunaTheFoxgirl]

@LunaTheFoxgirl is the frameworks test invoking the linker on osx? On my linux dub build simply builds a static library so there's no linking done if you specify a configuration without a target type.

Yes, it is linking given that it's using a symbol that needs to be resolved whether or not it's an executable. That being said the config should ensure it's compiled as an executable; but only on Darwin targets.

Is no-op if targeting anything else.

[the-horo]

You can "use" a symbol at compile time and have it be unresolved. It will fail at link time. I am asking specifically because I can dub build that file on linux without it failing (because a static library is not linked). Is it the same on osx? Would the test pass without the frameworks in dub.sdl because there's no linking being done? If so, the test needs to be fixed to include the executable targetType.

[LunaTheFoxgirl]

You can "use" a symbol at compile time and have it be unresolved. It will fail at link time. I am asking specifically because I can dub build that file on linux without it failing (because a static library is not linked). Is it the same on osx? Would the test pass without the frameworks in dub.sdl because there's no linking being done? If so, the test needs to be fixed to include the executable targetType.

In my experience that is behavior exclusive to Linux. Has never happened to me on macOS or Windows.

I think the object file structure of macOS and Windows more or less requires linking to be done or weak be applied before such behavior presents itself for those. As mach-o objects themselves store library reference data. And same with PE/COFF objects, if I understand that spec correctly.

Also in my local testing an executable mach-o file was created.

[LunaTheFoxgirl]

That being said; being more clear by adding targetType would be a good idea. Should be done in a separate PR though since this one's already merged.

[rikkimax]

You can "use" a symbol at compile time and have it be unresolved. It will fail at link time. I am asking specifically because I can dub build that file on linux without it failing (because a static library is not linked). Is it the same on osx? Would the test pass without the frameworks in dub.sdl because there's no linking being done? If so, the test needs to be fixed to include the executable targetType.

In my experience that is behavior exclusive to Linux. Has never happened to me on macOS or Windows.

I think the object file structure of macOS and Windows more or less requires linking to be done or weak be applied before such behavior presents itself for those. As mach-o objects themselves store library reference data. And same with PE/COFF objects, if I understand that spec correctly.

Also in my local testing an executable mach-o file was created.

Something here appears to be miscommunicated.

You can use any symbol that you want to as far as the D compiler is concerned.
Static libraries are produced by archivers, not linkers. They do no symbol resolution.

Linkers do most of symbol resolution, but not all. Usually you must communicate to the linker which binary includes a given symbol if its not found within the object files you passed to it.

Loaders will do the final symbol resolution.

The only way to know for certain that a symbol has been resolved is to use it. Anything other than this can have it be ignored.