Using ldc2 (1.25.0 (DMD v2.095.1, LLVM 10.0.0) or dmd (DMD64 D Compiler v2.095.0), compiling the following test code:
test.d:
import std.experimental.logger : info;
void main() {
info("hello");
}
using: dmd -makedeps=deps.txt test.d
generates:
test.d \
/usr/include/dmd/phobos/std/experimental/logger/package.d \
/usr/include/dmd/druntime/import/object.d \
/usr/include/dmd/druntime/import/core/attribute.d \
...
/usr/include/dmd/druntime/import/core/stdc/fenv.d \
test_loggerconfig.d \
/usr/include/dmd/druntime/import/core/sys/linux/time.d
Note the test_loggerconfig.d. This dependency is only generated if info() is used somewhere in the code, i.e. it is not triggered if the body of main is empty in the example above.
info() is an alias leading to the template defaultLogFunction in std.experimental.logger.core.d
This is an excerpt from the logger.core.d code:
template moduleLogLevel(string moduleName)
if (moduleName.length)
{
import std.string : format;
mixin(q{
static if (__traits(compiles, {import %1$s : logLevel;}))
{
import %1$s : logLevel;
I guess the import-in-mixin might be throwing off the makedeps logic?
This implicit non-existing dependency causes meson/ninja to recompile each time it is invoked
Cheers!
Comment #1 by tobias — 2022-03-04T10:03:42Z
mir-core has the same problem, which also boils down to __traits(compiles, import <module>), adding a file to the makedeps.
One could argue, that it is correct to add files to the makedeps, but given multiple import paths it's hard to do it correctly.