`--arch` flag is ignored when building ddox/dscanner tools, `defaultArchitecture` from settings used instead

[PetarKirov]

--arch flag is ignored when building ddox/dscanner tools, defaultArchitecture from settings used instead

Summary

When dub.settings.json sets defaultArchitecture to a cross-compilation target (e.g. wasm32-unknown-unknown-wasm), the -b ddox and -b lint build types fail because they build their respective tools (ddox, dscanner) using defaultArchitecture instead of the host's native architecture — even when --arch is explicitly passed on the command line.

Reproduction

mkdir /tmp/ddox-bug && cd /tmp/ddox-bug

cat > dub.sdl << 'EOF'
name "test"
targetType "library"
sourcePaths "src"
importPaths "src"
EOF

cat > dub.settings.json << 'EOF'
{
    "defaultArchitecture": "wasm32-unknown-unknown-wasm",
    "defaultCompiler": "ldc2"
}
EOF

mkdir -p src
cat > src/test.d << 'EOF'
/// Test module
module test;
/// A test function
void foo() {}
EOF

dub build -b ddox --arch=x86_64

Output:

Starting Performing "ddox" build using ldc2 for x86_64.
Building test ~master [library]
Error Could not resolve configuration for package hyphenate

Expected: ddox should build and generate documentation successfully, since the explicit --arch=x86_64 should apply to the ddox tool build as well (or ddox should always be built for the native host architecture).

Removing dub.settings.json (or the defaultArchitecture key) makes dub build -b ddox succeed.

Root Cause

runDdox() in source/dub/dub.d creates a separate Dub instance for building the ddox tool and calls makeAppSettings() to determine the build platform:

auto ddox_dub = new Dub(null, m_packageSuppliers);
ddox_dub.loadPackage(tool_pack);
ddox_dub.upgrade(UpgradeOptions.select);

GeneratorSettings settings = this.makeAppSettings();
// ...
ddox_dub.generateProject("build", settings);

makeAppSettings() determines the platform using this.defaultArchitecture, which reads from dub.settings.json:

settings.platform = settings.compiler.determinePlatform(
    settings.buildSettings, compiler_binary, this.defaultArchitecture);

This completely ignores the user's --arch flag — which was only stored in the PackageBuildCommand scope and applied to the main project build, but never forwarded to makeAppSettings().

When defaultArchitecture is wasm32-unknown-unknown-wasm, the ddox dependency hyphenate (which requires Phobos and platform-specific modules) cannot resolve a valid configuration for that target.

Affected Code Paths

The same pattern affects multiple tool-building functions:

• runDdox() — builds the ddox documentation tool
• lintProject() — builds the dscanner linting tool
• runCustomInitialization() — builds template init tools

All of these create a separate Dub instance and use makeAppSettings(), inheriting the cross-compilation defaultArchitecture instead of the native host architecture.

Suggested Fix

Tool builds (ddox, dscanner, etc.) are executables that run on the host machine, so they should either:

1. Always use the native host architecture (ignoring defaultArchitecture), or
2. Forward the user's --arch flag to makeAppSettings() when building tools

Option 1 seems more correct, since these tools must run natively regardless of the project's target architecture.

Environment

• dub: 1.39.0
• ldc2: 1.41.0
• OS: NixOS x86_64-linux