move grouping of UNIFIED_SOURCES to the frontend, rather than the recursivemake backend

RESOLVED INCOMPLETE

Status

RESOLVED INCOMPLETE
4 years ago
8 months ago

People

(Reporter: froydnj, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

We currently figure out the UnifiedFoo.cpp -> [#include'd files] mapping in recursivemake.py:

http://mxr.mozilla.org/mozilla-central/source/python/mozbuild/mozbuild/backend/recursivemake.py#401

This is a layering violation; we should be computing this someplace else.

In a similar fashion, we write out the unified files themselves in the unified make backend:

http://mxr.mozilla.org/mozilla-central/source/python/mozbuild/mozbuild/backend/recursivemake.py#416

This is also a layering violation; we should be writing these files someplace else.

The "someplace else" in both cases is different:

- We want to compute the mapping between files in the frontend:

http://mxr.mozilla.org/mozilla-central/source/python/mozbuild/mozbuild/frontend/data.py#770

- We want to write out the files in the common backend.

And it's the second one that is a problem, because our current design for processing objects emitted by the frontend looks like:

1. subclassing backend calls super().consume_object:

http://mxr.mozilla.org/mozilla-central/source/python/mozbuild/mozbuild/backend/common.py#183

2. If the common backend didn't consume the object, the subclassing backend does whatever it likes.

In the case of writing out the unified files, however, we want *both* backends to do useful things: the common backend should write out the unified files, while the subclassing backend (recursivemake, mostly) will add the necessary makefile logic.

The most straightforward solution is to have the common backend call into a hook function for subclasses (for UnifiedSources only, but I suspect we will need more instances of this in the future), so the call chain looks like:

  subclass.consume_object:
    CommonBackend.consume_object:
      subclass._sub_handle_unified_sources

Bikeshedding on the names welcome.

(I wonder if we should really structure things so CommonBackend.consume_object drives everything, calling subclassing methods as appropriate...)
This is all easier to do in the visual studio bug, so that we can update all the backends in the same bug.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INCOMPLETE

Updated

8 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.