How to install Python package from source on Windows

[bartc]

On 18/05/2017 12:37, Rhodri James wrote:
> On 18/05/17 02:12, bartc wrote:
>>> So tell us Bart, what do you think are the chances that your Q
>>> compiler will
>>> *just work* with no modifications at all if somebody tried to build
>>> it on
>>> an IBM AS/400, or under BeOS?
>>
>> Maybe somebody can try it:
>>
>>     https://github.com/bartg/langs/blob/master/qlang/qcc64.c
>>     https://github.com/bartg/langs/blob/master/qlang/pcc64.c
>
> I don't have my RiscPC here at work, and anyway I'd need the 32-bit
> versions,

(Try same urls but with '32' substituted.)

  but I had a quick look.  I didn't get as far as checking if
> endianness would bite it,

Yes, it might well do (not having tested it, I don't know). But, so 
what? What am I supposed to do about it? If I had my hands on such a 
machine, I could try it out. And if there was actually such a problem, 
then I might fix it. But the last non-little-endian cpu I coded was in 1978.

  but (a) you have no leg to stand on
> criticising configure scripts with that file,

You think so?

After the first 50 lines, there are no #includes, no #defines, no #ifs 
or #ifdefs, in fact I think there are no uses of macros at all. And no 
#includes for anything other than a few standard C headers.

Everything referenced is also within that one file.

Utter bliss compared with my experience yesterday trying to get some 
CPython modules compiled. #defines, #includes and #ifs left right and 
centre. Code specific to MSC or GSC sprinkled like confetti (there's 
even an #include <windows.h> in there, God knows what is for). And the 
actual include files are all over the shop.

You lose the will to live chasing up every single thing that comes up. 
(I was trying out my own C compiler: it eventually got 2/3 of the way 
through ./Modules/main.c, but it reported wrong # of arguments to 
Py_FatalError. Where's Py_FatalError defined? I don't know.)

  and (b) I think you may be
> making assumptions about non-aligned pointers that will kill you on
> ARM3, and are horribly inefficient elsewhere.

I've just tried it on an original raspberry pi, with 32-bit ARM (can't 
tell you what type). My jpeg decoding benchmark ran about 4 times as 
fast as the Python version (with exactly the same algorithm), albeit 
with some ancient version of Python.

And my design lends itself to being easily accelerated by overlaying 
some ASM code (I do this on x64 but haven't got round to it on ARM).

-- 
bartc