Project fails to build

[nordlow]

In a private project of mine,

redub@~main test

fails as

Resolved: - 21 ms "debug" using /home/per/.local/dlang/linux/bin64/dmd v2.112.0-beta.1-480-g1b85a2e82b [linux-x86_64] - leaves parallel
Will Build: xls [debug]; blake3-d [debug]; nx-d [debug]; tcc-d2 [debug]; yyjson-d [debug]; 
Internal Error: Unexpected message type: expected '(ProcessInfo, CompilationResult)', got 'std.typecons.Tuple!(redub.building.compile.CompilationID, redub.building.compile.ProcessInfo, redub.building.compile.CompilationResult).Tuple'
Error Program exited with code 1

.

[per:~] $ redub@~main --version

outputs

Redub v1.25.7 - A reimagined DUB. Built With LDC v2.112 at Oct 22 2025

. The project is in stealth mode so can only share parts of the project starting with dub.sdl containing

targetType "executable"
license "BSL-1.0"
targetPath "bin"

mainSourceFile "src/app.d"

dependency "nx-d" path="../nx-d"
dependency "tcc-d2" path="../nx-d/tcc-d2" # TODO: apt install libtcc-dev on demand
dependency "blake3-d" path="../../blake3-d"
dependency "yyjson-d" path="../../yyjson-d"

preBuildCommands "bash provision.sh" # ok because no-changes takes ~5ms
preRunCommands "bash provision.sh" # ok because no-changes takes ~5ms

dflags "-Xcc=-fuse-ld=lld"
lflags "-fuse-ld=lld"

# Disabled: Shared Library linking with libtree-sitter.so:
# lflags "-L$PACKAGE_DIR/installs/tree-sitter/lib" "-rpath=$PACKAGE_DIR/installs/tree-sitter/lib"
#libs "tree-sitter"

# Static linking of `libtree-sitter.a` to be sure the modified `struct TSNode` is used
lflags "$PACKAGE_DIR/installs/tree-sitter/lib/libtree-sitter.a"

dflags "-Xcc=-fuse-ld=lld" "-preview=in" "-preview=fieldwise" "-preview=bitfields" "-preview=dip1000" "-preview=dip1008" "-preview=rvaluerefparam" # TODO: "-preview=dip1021"

configuration "debug" {
   dflags "-g" "-checkaction=context" "-allinst"
   dflags "-debug" platform="dmd"
   dflags "--d-debug" platform="ldc"
   dflags "-fsanitize=address" platform="posix-ldc"
   lflags "--export-dynamic" platform="posix" # for ASan backtraces
}

configuration "unittest" {
   versions "xls_test"
   dflags "-g" "-checkaction=context" "-allinst" "-unittest"
   dflags "-debug" platform="dmd"
   dflags "--d-debug" platform="ldc"
   dflags "-fsanitize=address" platform="posix-ldc"
   lflags "--export-dynamic" platform="posix" # for ASan backtraces
}

buildType "unittest" {
   versions "xls_test"
   dflags "-g" "-checkaction=context" "-allinst" "-unittest"
   dflags "-debug" platform="dmd"
   dflags "--d-debug" platform="ldc"
   dflags "-fsanitize=address" platform="posix-ldc"
   lflags "--export-dynamic" platform="posix" # for ASan backtraces
}

. Project builds with dub.

[MrcSnm]

Ok I've got what the bug is, looks like I've improved only fully parallelized and not parallel simple. It is the first time I've saw a project which is not fully parallelizable :O

[MrcSnm]

Just fixed and issued a new release for it. In case you're interested, that issue happened because --parallel=leaves were inferred because you're using preBuildCommand or postBuildCommands.

bool isFullyParallelizable()
    {
        bool parallelizable =
            requirements.cfg.preBuildCommands.length == 0 &&
            requirements.cfg.postBuildCommands.length == 0;
        foreach(dep; dependencies)
        {
            parallelizable|= dep.isFullyParallelizable;
            if(!parallelizable) return false;
        }
        return parallelizable;
    }

That is the related code. If you don't think that is a good condition for fully parallel, please let me know since I usually don't use those commands

Get that fix by calling redub update

[nordlow]

Awesome! Will the build time in general improve via parallelization if I move the preBuildCommands and postBuildCommands? I use preBuildCommands for provisioning of C libraries using cmake and GNU make. The provisioning is cached so the second time the postBuildCommands finishes in about 10 ms. Would you in that case still advice against using preBuildCommands to enable maximum parallelization?

[MrcSnm]

Exactly, you can also try building it with --parallel=full and it will keep them even if you use preBuild/postBuild, since the default is --parallel=auto