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(a)redhat.com> 2010-12-16 20:45:39 EST ---
(In reply to comment #11)
...
1) 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.
4) 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)
5) 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?)
--
Configure bugmail:
https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.