On 6/24/2014 2:52 PM, Kim Gräsman wrote:
My initial instinct was to contribute Python3 support to pymake, but I got the impression from Gregory that Mozilla's long-term plan is to abandon pymake in favor of the now Windows-friendlier GNU Make 4, and that pymake is gradually becoming less maintained.
pymake was always a hacky project; we happened to use it in production for a while because it could do -jN builds on Windows while binary make would crash.
I started it primarily as a frontend for importing makefiles into other formats, so that Mozilla can gradually stop using makefiles altogether. So it does have an IR which you can use to build other tools.
In that light, I feel that there may be no point investing effort in pymake as such, especially since we don't need a full Make implementation. So now I'm considering forking a separate project covering only Makefile parsing and some kind of semantic Makefile model, probably heavily inspired by pymake. Does this make sense, or are there strong pymake supporters who would accept patches to improve packaging and py3k support?
I encourage you to branch from the existing pymake tree and do whatever stuff you need. I also encourage you to keep a fully functional make backend, not just the parsing/semantic frontend bits: that's really the only way I had to prove that the parser was emitting the correct code, and it turns out that in many cases it wasn't.
We're definitely stuck with py2k, so it would be nice to keep the code 2k/3k compatible. Otherwise it will be an unmergeable fork.
--BDS _______________________________________________ dev-builds mailing list [email protected] https://lists.mozilla.org/listinfo/dev-builds
