How to install Python package from source on Windows

[Chris Angelico]

On Sun, May 21, 2017 at 4:11 AM, bartc <bc at freeuk.com> wrote:
> On 20/05/2017 17:49, Chris Angelico wrote:
>>
>> On Sat, May 20, 2017 at 8:46 AM, Viktor Hagström
>> <viktor.hagstrom at outlook.com> wrote:
>>>
>>> I have followed this discussion since the beginning, and I have been
>>> intrigued. I recently read a relevant blog post that I'd like to share. It
>>> has arguments for both sides: http://nullprogram.com/blog/2017/03/30/.
>
>
>> Truly portable code either targets the lowest common denominator,
>> which means avoiding any sort of file system processing or any
>> features not in C89, or has multiple branches. That's the only two
>> ways to do it.
>
>
> Why avoid file processing? Standard C has long had fopen and fclose, and a
> handful of other functions (basically to read files and to write them). You
> don't need much else.

What's a file name consist of? Is it:

* A series of bytes, terminated by \x00?
* A series of bytes that must be decodable as UTF-8?
* A series of sixteen-bit units which may or may not be decodable as UTF-16?

What byte values and what character values are legal? How do you
describe a path, or can you only work in the current directory? What
is a drive letter, can you use it, and what happens if you omit it?

The answers to these questions are not the same on all of today's
platforms - and that's even assuming that you can ignore older systems
like the pre-BSD Mac OS, or the Amiga.

You can *probably* restrict yourself to the current directory and to a
limited set of safe file name characters (all of which are ASCII, but
not all of ASCII is safe). Probably. But I wouldn't bet my life on
even that.

> ...Keep the build as simple as possible."
>
> (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

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.

> It still doesn't work though because you can get down to just a single file,
> and people will still moan that it's too complex. You've reduced the job of
> building a set of kitchen units to hammering in just one nail, but then find
> that someone has never hammered a nail in before.
>
> I'm now investigating how to reduce a project to no files at all!)

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.

ChrisA