On 7/10/2014 11:10 AM, Kim Gräsman wrote:
On Mon, Jul 7, 2014 at 10:24 PM, Kim Gräsman <[email protected]
<mailto:[email protected]>> wrote:
It seems to me the way forward is to attack the circular dependencies
head-on on a couple of fronts:
- command-process-jobs can be split up into independent parts by
moving job-related stuff to new jobs module and moving
call/call_native from process to command
- all exceptions can be safely moved into an pymake.errors module,
which reduces irrelevant dependencies on data, parser and process
- parserdata.Location and parser.Data have no outgoing dependencies
and can be moved to their own module (e.g. pymake.values)
- the SOURCE_ and FLAVOR_ flags seem to be used from a number of
places and might make sense in the same module, to disassociate them
from the heavy data module
I've spent some time experimenting with these, and it clears up some
of the circularity. Unfortunately, far from all of it. The data,
parserdata, parser and functions modules all have two-way dependencies
between each other.
This is mostly inherent in the make processing model itself. Because of
$(eval), function evaluation has a "backwards" dependency on the parser
module.
Maybe I don't understand the problem with circular deps in this case.
Can we solve it using relative imports?
--BDS
_______________________________________________
dev-builds mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-builds