I have the following in my dub.json file:
{
"preGenerateCommands": [ "$DUB source/scpp/build.d" ],
}Permalink: https://github.com/bpfkorea/agora/blob/952cd01b14778d5ca5e34c049c8217c59037614f/dub.json#L14
This calls a build file that builds a C++ library. The build file itself doesn't use any of dub's features, it's only here to be cross platform (because rdmd wasn't working well for a reason I forgot).
This is literally the package definition of the build.d file:
#!/usr/bin/env dub
/+
dub.json:
{
"name": "cpp_build"
}
+/Permalink: https://github.com/bpfkorea/agora/blob/952cd01b14778d5ca5e34c049c8217c59037614f/source/scpp/build.d#L1-L7
I put a -v in my $DUB invocation just to see what happens, and lo and behold found a few issues.
This is the flags I see when the compiler is invoked:
$ ldc2 -extern-std=c++14 -preview=in -extern-std=c++14 -c -ofsource/scpp/.dub/build/application-$DFLAGS-posix.osx.darwin-x86_64-ldc_2093-CEAA0795D0F4AF6821A572E766E19528/cpp_build.o -w -oq -od=.dub/obj -d-version=Have_cpp_build source/scpp/build.d -vcolumns
Linking...
ldc2 -ofsource/scpp/.dub/build/application-$DFLAGS-posix.osx.darwin-x86_64-ldc_2093-CEAA0795D0F4AF6821A572E766E19528/cpp_build source/scpp/.dub/build/application-$DFLAGS-posix.osx.darwin-x86_64-ldc_2093-CEAA0795D0F4AF6821A572E766E19528/cpp_build.o
My original call, in the parent package, was dub test --compiler=dmd. dub points to the one distributed with dmd-2.094.0-beta.1, through the install script. So by default this bug should select dmd, right ?
Issue 1: ldc2 is used. Because my dub.settings.json uses ldc2 as default compiler. Obviously I override this with --compiler, but the nested one doesn't pick it up. That might be a sensible behavior, but it's a very surprising one. Conversely, if I had no dub.settings.json, dub would always use dmd regardless of what --compiler I provide.
Issue 2: What are those -extern-std=c++14 -preview=in -extern-std=c++14 flags ? The duplication is a tiny thing in the package and can be ignored. But the problem is that the parent package exports the flags as DFLAGS, which always forces the inner invocation to pick it up. That's especially problematic because not everything is propagated. The compiler, for starter, and perhaps the LFLAGS.
Issue 3: To add to the inconsistency, the root path dub seems to use is source/scpp (where the file lives), according to where the object is built. That's a behavior I think is sane, however it contradicts what dub does with the local dub.settings.json.
In short, I think dub some/single/file.d should behave as dub --root some/single/ --single path.d and the parent dflags shouldn't propagate to the child.
I have the following in my
dub.jsonfile:Permalink: https://github.com/bpfkorea/agora/blob/952cd01b14778d5ca5e34c049c8217c59037614f/dub.json#L14
This calls a build file that builds a C++ library. The build file itself doesn't use any of
dub's features, it's only here to be cross platform (becauserdmdwasn't working well for a reason I forgot).This is literally the package definition of the
build.dfile:Permalink: https://github.com/bpfkorea/agora/blob/952cd01b14778d5ca5e34c049c8217c59037614f/source/scpp/build.d#L1-L7
I put a
-vin my$DUBinvocation just to see what happens, and lo and behold found a few issues.This is the flags I see when the compiler is invoked:
My original call, in the parent package, was
dub test --compiler=dmd.dubpoints to the one distributed withdmd-2.094.0-beta.1, through the install script. So by default this bug should selectdmd, right ?Issue 1:
ldc2is used. Because mydub.settings.jsonusesldc2as default compiler. Obviously I override this with--compiler, but the nested one doesn't pick it up. That might be a sensible behavior, but it's a very surprising one. Conversely, if I had nodub.settings.json,dubwould always usedmdregardless of what--compilerI provide.Issue 2: What are those
-extern-std=c++14 -preview=in -extern-std=c++14flags ? The duplication is a tiny thing in the package and can be ignored. But the problem is that the parent package exports the flags asDFLAGS, which always forces the inner invocation to pick it up. That's especially problematic because not everything is propagated. The compiler, for starter, and perhaps theLFLAGS.Issue 3: To add to the inconsistency, the root path
dubseems to use issource/scpp(where the file lives), according to where the object is built. That's a behavior I think is sane, however it contradicts whatdubdoes with the localdub.settings.json.In short, I think
dub some/single/file.dshould behave asdub --root some/single/ --single path.dand the parent dflags shouldn't propagate to the child.