On 6/24/14, 1:20 PM, Kim Gräsman wrote:
On Tue, Jun 24, 2014 at 9:53 PM, Benjamin Smedberg
<[email protected]> wrote:
On 6/24/2014 3:39 PM, Kim Gräsman wrote:
The message I'm hearing is that you _do_ see a future for pymake, and
would rather not rip out a separate project, is that right?
"future" is a strong word. Mozilla is unlikely to make future improvements
to the project, but it mostly-works now.
So to the extent that we can improve the current code and avoid multiple
forks, having a shared codebase is usually a win for everyone.
Makes perfect sense, and I agree that a single codebase is better.
There are certainly makefile evaluation patterns that aren't statically
analyzable: $(eval) in particular can change things. But it's definitely
possible to statically parse a makefile and its variables into an IR and
often that's enough to do interesting transforms. Worse is better ;-)
:-) We're looking at pretty simple pared-down variable definitions +
conditionals, so I think we can get by with the IR, but I'd have to
play with it to make sure.
As for a fork, here are some things I need to know before I can get down to it:
- Is the master repo at
http://hg.mozilla.org/users/bsmedberg_mozilla.com/pymake/?
Yes.
- Can I ask questions on this list? Send patches for review?
I vote for converting the repo to Git and throwing it up at
github.com/mozilla/pymake.
Benjamin?
- How careful do I need to be with library structure stability? Do you
have a lot of Python code using pymake as a library or is the make.py
driver the primary entry point? I'd like to start with setuptools
packaging for pymake, and that would require some cleaning up of
imports (e.g. ``import pymake.data`` instead of ``import data``.)
We have a few tools that talk to the internals, but nothing major.
Unless you are doing crazy refactoring (which I doubt you'll want to due
to the complexities of pymake), I don't think rebasing will be much
trouble. As long as you don't change the version of pymake in Firefox's
repo, I don't think anyone at Mozilla will care.
- If I can get packaging set up, I'd like to have pymake published to
pypi. Unfortunately, there's already a pymake on there
(https://pypi.python.org/pypi/pymake/0.9) but it looks abandoned, so I
could figure something out with the author.
+1
- How do I test it? I found a tests/runtests.py; is that sufficient?
Hoping I don't have to build Firefox after every change.
pymake has its own test suite that is independent of Firefox.
- Performance implications -- if I make changes and inadvertently
worsen performance, can I find out somehow, or will people just hate
me?
pymake is already way slower than make. I doubt you will make it much
worse. Building Firefox is a great stress test of pymake. Even just
building a single directory (like dom/, content/, or toolkit/) would be
a good benchmark.
_______________________________________________
dev-builds mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-builds
