Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=588941
--- Comment #32 from Dave Malcolm dmalcolm@redhat.com 2010-12-16 20:45:39 EST --- (In reply to comment #11) ...
- License tag is better. dmalcolm: I found the list of licenses that had
been included in the spec file present in the LICENSE file. If that's where you got the original list from then the license tag should now be correct. I was able to remove LGPL and Distributable because those were coming from bundled jar files. I removed the bundled jars (see below) so that should now be fine.
The LICENSE file is indeed where I got that list from. I haven't yet gone through the full tarball payload.
- The build isn't make driven but I didn't look at parallelizing it.
The compilation phase invokes a Makefile; on my machine it used "-j 4", and in one of the Koji scratch builds it used "-j 10" It appears to come from this code in pypy-1.4/pypy/translator/c/genc.py:compile:
if self.config.translation.make_jobs != 1: extra_opts += ['-j', str(self.config.translation.make_jobs)]
which in turn is intialized in this code in pypy-1.4/pypy/config/translationoption.py: cmdline="--make-jobs", default=detect_number_of_processors()),
Hopefully that's good enough for our build system.
It's actually visible in the built binary, FWIW:
$ ./pypy --info|grep make_jobs translation.make_jobs: 4
Unfortunately that parallelizable phase is only a small fraction of the build time (see "compile_c" below); from the x86_64 scratch build's log: [Timer] Timings: [Timer] annotate --- 780.8 s [Timer] rtype_lltype --- 491.7 s [Timer] pyjitpl_lltype --- 712.2 s [Timer] backendopt_lltype --- 202.3 s [Timer] stackcheckinsertion_lltype --- 21.6 s [Timer] database_c --- 243.8 s [Timer] source_c --- 477.3 s [Timer] compile_c --- 148.4 s [Timer] =========================================== [Timer] Total: --- 3078.2 s real 52m21.339s user 49m43.905s sys 0m3.552s
so roughly 15% of that build time benefited from the 10 cores on that machine (presumably, would have been ~1480 seconds otherwise, so that at least is a significant saving).
As I understand it, parallelizing the rest of the build would involve major rewrites (it's all in one big cpython process)
- rpmlint c): Yeah, it's because it's named -libs. Another possible name is
-stdlib since it is the python stdlib(for pypy).
Did moving to versioned requirements fix this?
5e) I was waiting for the koji build to complete to see if this is still an issue with 1.4.
Seems to have been fixed, either in 1.4, or in Toshio's work on the specfile.
5f) dmalcolm, what did we decide to do with this on the python and python3 packages?
I've copied a fixer-upper from the python3 specfile in my 1.4-4 pypy.spec
Other:
- Removed bundled jar files. Pre-built files are not allowed. It looks like
these were present in case we were building a pypy that targets the jvm (rather than POSIX-C). Simple removal should be fine until/unless we want to enable that backend. If we do enable that, one of the jar files is packaged for
BTW, I considered building that one. The impression I get is that the JVM backend isn't as mature as the .c backend, so it seems simplest to omit it for now. (fijal: do you have any advice/guidance on this?)