How to install Python package from source on Windows

[bartc]

On 20/05/2017 19:37, Chris Angelico wrote:
> On Sun, May 21, 2017 at 4:11 AM, bartc <bc at freeuk.com> wrote:

>> (Which is exactly what I strive to do. Although my projects are small, they
>> could still involve dozens of source and support files, and require running
>> non-standard tools to build, which would then require other sets of sources
>> to built those.
>
> Dozens? Oh you poor wee lamb.
>
> rosuav at sikorsky:~/cpython$ find -name \*.c -or -name \*.h | wc -l
> 672
>
> rosuav at sikorsky:~/pike$ find -name \*.c -or -name \*.h | wc -l
> 701
>
> rosuav at sikorsky:~/wine$ find -name \*.c -or -name \*.h | wc -l
> 3981
>
> rosuav at sikorsky:~/linux$ find -name \*.c -or -name \*.h | wc -l
> 44546

This is rather fascinating actually.

Of those remarks I quoted it said that VS/Cmake took 17 minutes to do 
something instead of 2 minutes, or 1 second to check something instead 
of 20 seconds. What /I/ would like to know is, what is VS/Cmake *doing* 
in those extra 15 minutes, or the extra 19 seconds.

I would say there are two types of people: those who care about the 
answer, and those who don't.

And similarly, I'd quite like to know what all those 44546 files are 
for. I remember that Debian on Raspberry Pi reported there were 55,000 
files installed, yet every time you wanted to actually DO anything, you 
needed a sudo apt-get install!

There is some skill involved I think in keeping things small and 
manageable and at a human scale. I think that's largely been lost.

> These repositories, by the way, correspond to git URLs
> https://github.com/python/cpython,
> git://pike-git.lysator.liu.se/pike.git,
> git://source.winehq.org/git/wine, and
> https://github.com/torvalds/linux respectively, if you want to check
> my numbers. Two language interpreters, a popular execution subsystem,
> and an OS kernel.
>
> I'd like to see you create a single-file version of the Linux kernel
> that compiles flawlessly on any modern compiler and has no configure
> script.

I've written plenty of code to talk to the sort of hardware that I 
assume OSes are still largely concerned with. Those drivers were tiny; 
what's happened to make them so huge?

(Applications I wrote in the 80s had to DIRECTLY deal with colour 
graphics, pointing devices, fonts, printers and plotters. With multiple 
drivers for each graphics card, printer etc. /And/ emulate floating 
point. /And/ emulate virtual memory that swapped itself to disk. The OS 
only took care of the keyboard, and the file system. Yet, the entire 
application was STILL tiny!)

BTW /does/ Linux compile on /any/ modern compiler? I heard it was so 
difficult to compile that gcc had to be specially modified to make it 
possible.

> Good, you do that. That fits in the same sort of puzzle space as
> building a Turing tarpit. Meanwhile, the rest of us are actually doing
> useful things with our lives.

Trying to keep the world simple isn't useful? Someone has to keep tabs 
on such things before technology grinds to a halt under the weight of 
all the software.

-- 
bartc