Moving C++ files between directories requires clobber: "No rule to make target '.../Example.cpp', needed by 'Example.o'"

NEW
Unassigned

Status

defect
2 years ago
Last year

People

(Reporter: jld, Unassigned)

Tracking

(Blocks 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

I have a situation where builds fail like this if I don't clobber:

 0:15.37 make[4]: *** No rule to make target '/home/jld/src/gecko-dev/security/sandbox/linux/LinuxCapabilities.cpp', needed by 'LinuxCapabilities.o'.  Stop.
 0:15.37 /home/jld/src/gecko-dev/config/recurse.mk:73: recipe for target 'security/sandbox/linux/launch/target' failed

The use case that's breaking is probably unusual: moving LinuxCapabilities.cpp from security/sandbox/linux to .../launch and changing .../launch/moz.build to use 'LinuxCapabilities.cpp' instead of '../LinuxCapabilities.cpp'.

The larger context is that the code that's using LinuxCapabilities is being rewritten, the current version being in security/sandbox/linux (libmozsandbox) and the future version being in .../launch (libxul), but I want the two versions to coexist for a while (selectable at runtime for troubleshooting) until we're reasonably sure it's stable.

So, the file is moving between directories, but there's still a moz.build in the same directory referencing it by a different path (with the same basename), and the build system seems to not pick up the change and is still trying to find it in the old location.

(It occurs to me, now that I know what's going on, that I could avoid the clobber by exporting the symbols from libmozsandbox instead of duplicating the module — which is usually a good idea anyway, although in this case the module is tiny enough that an extra copy probably isn't noticeable.)

This may be a duplicate of 1050912, which was WORKSFORME'ed, but I can reliably reproduce it.
so if you look at $objdir/security/sandbox/linux/.deps/LinuxCapabilities.o.pp you'll see:

LinuxCapabilities.o: \
 /build/mozilla-central/security/sandbox/linux/LinuxCapabilities.cpp \
<...>

But since there's no rule for that source file, make just gives up. We do run gcc with -MP:
https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html#index-MP

so it outputs a dummy target for all the headers listed, so that if you remove one of them it'll forcibly rebuild, but there's no option to do the same for source files, apparently.

Updated

Last year
Product: Core → Firefox Build System
A number of people are experiencing this after bug 1459785 landed (for the first time), see bug 1459785 comment 8 and following.
You need to log in before you can comment on or make changes to this bug.