Open Bug 1154232 Opened 9 years ago Updated 2 years ago

Bug 1146355 may have needed a clobber

Categories

(Firefox Build System :: General, defect)

defect

Tracking

(firefox40 affected)

Tracking Status
firefox40 --- affected

People

(Reporter: Ms2ger, Unassigned)

References

Details

tzimmermann touched CLOBBER there without explanation, doesn't even know if it was actually necessary and refuses to file a bug himself, so it seems more efficient to file this bug myself rather than arguing until he does his job.
C'mon, no need to get snarky!

For reference, the issue I saw is the missing-dependency scenario described in [1].

Regarding 'doing his job,' the exact meaning and purpose of CLOBBER is a mystery to me and many other developers I asked about it. It'd be helpful to have a simple and clear checklist for when to update CLOBBER.

[1] http://gittup.org/blog/2014/03/6-clobber-builds-part-1---missing-dependencies/
Currently, I move and merge a number number of source files in the Bluetooth module. Removing files results in dependency errors where the build system looks for the old file.

An example is in [1]. The file `../../../gecko/dom/bluetooth/bluetooth1/BluetoothInterface.cpp' had been removed as part of the patch set.

[1] https://treeherder.mozilla.org/logviewer.html#?job_id=1724762&repo=b2g-inbound
See Also: → 1154669
The problem here is the old .cpp path still exists in the gcc-generated .deps/BluetoothInterface.o.pp file:

BluetoothInterface.o: \
 /home/mshal/B2G/gecko/dom/bluetooth/bluetooth1/BluetoothInterface.cpp \

We use -MP to create bogus rules for the header files in case those are renamed/removed, but unfortunately that doesn't generate one for the .cpp file. So when the moz.build file is updated and generates a new backend.mk, our rule from rules.mk points to the correct BluetoothInterface.cpp. But since BluetoothInterface.o is still in OBJS, we bring in the old BluetoothInterface.o.pp which has the invalid dependency. If a .cpp file is just flat-out removed from the build system we don't hit this problem, because although the old .pp file still lingers in the file-system, it is not included since it isn't in OBJS.

Any thoughts on how to fix this? Maybe we can append a fake rule into the .pp file for the cpp file similar to what gcc does for the headers? Or we could have a blanket '%.cpp:' rule that prints something like "Couldn't find $@, skipping"? With a fake rule in place, make is still able to point gcc to the correct cpp file from rules.mk, and then once gcc executes it'll overwrite the .pp file with the correct dependencies.
Product: Core → Firefox Build System
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.