[binarycrusader]

Has the build process for PyPy been simplified any? Is it more thoroughly documented now?

Attempting to port it to a new platform seemed an exercise in futility. Every time the build failed and I had to go fix something, I had to start the build from the beginning again. I gave up after a few days.

Given that the build took a few hours on a high-end Xeon workstation with plenty of I/O and memory, I remain hesitant to attempt that again.

[fijal]

First, please stop spreading FUD. It does not take "a few hours", it takes ~30-40min. That's pretty bad, but not the end of the world.

Second, you don't "just" try to build it - there is an extensive test suite that should be made to pass before you even try building the thing. We're not completely crazy, we won't wait "a few hours" before every single change can be tested.

I know it kind of makes it "boring work" instead of "interesting ranting", but this is the reality.

[illumen]

I can't see an architecture doc, or other docs describing the build toolchain. Since pypy doesn't use commonly used build tools (or does it?) porting is going to be harder than something that uses a well know build toolchain like autotools/cmake/etc for example.

What would a high level porting strategy be? Get it running on CPython first, run tests..., set up platform specific details in files X,Y,Z, then try and translate? Perhaps the people who did the ARM port could write a short post on the strategy they took? What things can you disable to get a minimal pypy working first?

CPython has a short Porting document of which the style could be mostly copied and improved on with pypy specific details. https://github.com/python-git/python/blob/master/Misc/Portin...

I like the "Bang on it until you get a >>> prompt" :)

[fijal]

There is an architecture doc, but definitely there is no porting guide. I would start with sending a mail to pypy-dev or asking on IRC, but generally "get the tests running first, all of them" is a good start.

[binarycrusader]

I'm sorry, it is most certainly NOT "FUD".

I have an Intel(R) Xeon(R) CPU W3540 @ 2.93GHz workstation with two 500GB drives and 12GB of memory.

The last time I ran the build process, it took hours while PyPy drew pretty pictures on the screen in ascii:

https://twitter.com/erikjanss/status/112867649666564096

All I did was run the standard build target following the documentation provided.

My understanding is that while it's busy drawing pretty ascii art (which I have no problem with, by the way) it's building PyPy from the RPython source, which according to other users as recently as December of 2012 "takes ages":

https://groups.google.com/forum/#!msg/julia-dev/4TeGQh8wbmI/...

Hence why I asked if this had been improved yet.

I'm not trolling, or spreading FUD. I'm asking if a significantly negative experience I had has been improved.

[coldtea]

>First, please stop spreading FUD

One person's subjective opinion of the time taken (which could even be objective, if it takes > 1 hour on HIS system), even exaggerated != FUD.

The term FUD is about an INTENTED, SMEAR campaign. Let's leave it to the era of the MS-Wars, where it belongs.

[tshepang]

What are you referring to by 'new platform'? ARM?

[binarycrusader]

A currently unsupported OS platform on AMD64; one that Python supports, but PyPy does not.

[lucian1900]

I believe that is only the case for Windows, since there are pretty much no PyPy devs on Windows.

Don't build it yourself, it's a useless pain in the ass.

[binarycrusader]

PyPy doesn't yet run on some of the UNIX variants that Python supports.