Also, remove now useless assignment into self._backend_files.

Comment on attachment 828514 [details] [diff] [review] Raise an exception when unhandled type received in consume_object Review of attachment 828514 [details] [diff] [review]: ----------------------------------------------------------------- Can you explain why you want to do this? If the backend isn't consuming a particular type, I think that will be pretty obvious because the build will fail to be correct. It will also highlight lapses in test coverage. I'm receptive to putting this in. I just want some additional context.

Comment on attachment 828514 [details] [diff] [review] Raise an exception when unhandled type received in consume_object Each time I've added a new object time to be consumed, I was stunned that it wouldn't complain when i ran config.status before adding the handling part in backend_files.

Here's something else to consider. It's likely that "special" build components like XPIDL and WebIDL will forever share some consumer/backend functionality. We have code in mozbuild.backend.common that already kinda/sorta takes this approach. A few times now I've started down the road of trying to inject super() into the mix so backends can be composed of multiple classes, each handling a very specific part of the build (like WebIDL). Even my patches in bug 928195 have all WebIDL object consuming happening in a separate class. This patch would break the recursive make backend because that backend explicitly chooses to defer processing of WebIDL classes to another class. I sympathize with the argument you are making though. Perhaps we should mark consumed objects somehow and enforce (from the emitter) that all objects sent "downstream" come back with a "yes I acked this object" bit set.

Something like this?

Now erroring out for unhandled SandboxWrapped too.

Comment on attachment 829117 [details] [diff] [review] Raise an exception when an emitted object is not acknowledged by the build backend Review of attachment 829117 [details] [diff] [review]: ----------------------------------------------------------------- Exactly what I was thinking!