On Sun, Jul 6, 2014 at 8:25 PM, Gregory Szorc <[email protected]> wrote: > > I anticipated this would be a difficult problem to solve. > > I would suggest two phases. > > First, get the naming sorted out. Ensure all modules are using relative > imports (from . import data) or are using fully qualified imports (from > pymake import data). > > Second, break the import cycles. If modules only have 1 or 2 references to > another module that's in a cycle, move the module-level import into a def. > As a follow-up, you can move things around to break the cycle. If you really > want to be hacky, you can have the "parent" module set attributes on the > "child" module for the symbols needed by the child. e.g.
Nice ideas. Some worked out, but I got stuck pretty soon on the aggressive module-to-module + cluster-to-cluster circular dependencies. We've burned our dev budget for pymake at the office and need to find a simpler solution for the narrow case we're looking at. I'll spend some free time trying to pull this together, though, because I think pymake could help solve lots of tooling problems. 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 - speculative: I think functions.py could be split up so that each module (data, parser, ...?) can contribute functions that operate on structures they supervise. E.g. data would provide SubstitutionRef because it depends on data.Pattern; parser would provide EvalFunction because it depends on parser.parsestring. Etc. Someone (pymake.command?) would need to orchestrate the building of the function map and pass it to parser, which seems to be the only user. These all seem like nice, small incremental improvements -- do they sound acceptable to you? If so, I can do them and send PRs incrementally and we'll see how hard the remaining cycles are. Thanks, - Kim _______________________________________________ dev-builds mailing list [email protected] https://lists.mozilla.org/listinfo/dev-builds
