How to install Python package from source on Windows

[Chris Angelico]

On Thu, May 18, 2017 at 5:32 AM, bartc <bc at freeuk.com> wrote:
> On 17/05/2017 17:23, Chris Angelico wrote:
>>
>> On Thu, May 18, 2017 at 1:37 AM, bartc <bc at freeuk.com> wrote:
>>>
>>> On 17/05/2017 15:13, Chris Angelico wrote:
>
>
>> [1] Does work on Windows. Install bash for Windows, or (on a
>> recent-enough Windows) just use the subsystem that Microsoft provides.
>
>
> So the answer is, switch to Linux. In other words, a cop-out.

No, I said "install bash". Since when does bash imply Linux? You can
get bash for any of the major platforms in use today. It's the default
user login shell on most Mac OS and Linux systems, as well as a good
smattering of other OSes.

>> [2] So? You don't have to read it, just run it. Or do you read every
>> line of code that any of your programs executes?
>
>
> Sometimes, if there's a problem. But usually the code is doing something
> sensible. The stuff in configure is complete gobbledygook (if anyone doesn't
> believe me, just have look).

That's because "configure" isn't source code. It's like someone
looking at your nasm files and moaning that they're unreadable. You
don't directly read or edit the configure script.

> It is impossible that all this is needed just to figure out what source
> files need to be compiled. (If it generated CPython sources fractal-style,
> then I might be impressed, but doesn't.)

I love how absolutely certain you are that this is *impossible*. Ahh,
that naivety again. Though in this case, you do happen to be correct:
it's doing more than merely figuring out which files to compile. It's
figuring out what libraries are available, what features are available
in those libraries, how the compiler produces object files, whether
the build environment is sane, and in some cases, enumerating all
available compilers so you can pick and choose. Imagine if your
compiler could detect whether nasm, tasm, masm, or gas is installed,
and emit appropriate assembly code for any of them. That's what you
need a configure script for.

>> How about if I put you on a different CPU than you're used to? Can you
>> use your tiny C compiler? I doubt it, because it's emitting Intel byte
>> code.
>
> I'm used to it. I used to start off with machines with no software in them
> at all. (Actually, I often needed to wire up the boards first.)
>
> The point I'm making is that these things should still work when reduced to
> the basics.

Define "basics". You seem to assume an Intel x86 CPU and nothing else,
or your program won't be any use. What's the point in reducing below
an OS if you're still depending on a specific line of CPUs? Are you
expecting to compile your own OS kernel? Type one in at the console?

> What it does show is that it is practical to reduce a substantial
> application to a single file, and trivially build it pretty much everywhere,
> as C compilers are ubiquitous. And that it will run with little trouble. The
> same source can run on ARM32, x86 and x64; Linux or Windows. Probably
> elsewhere but that is the extent of my tests.)

"substantial". Exactly how much code are you talking about? And how
portable does it need to be?

>> You're asking me to bootstrap Python. I would start by looking for the
>> nearest similar platform and trying to build a hybrid. I haven't done
>> this with Python itself, but a while ago, I wanted to port a
>> similarly-sized language to OS/2, and the process went like this:
>>
>> 1) Attempt to run the configure script, using bash and gcc (which
>> already existed for OS/2)
>
> I said bash didn't exist.
>
> (BTW I've gone down the route of installing MSYS etc many times, something
> always went wrong. Why is it that people can't appreciate that complicated
> thing are more likely to go wrong?)

Why would bash not exist? Or do you mean that it exists, but isn't installed?

>> Yes. Yes, it is. For starters, GCC actually can compile to machine
>> code, instead of depending on nasm.
>
>
> I don't think it does. gcc AFAIK generates assembly code (via pipes or
> equivalent so usually you don't see it), then invokes an assembler called
> 'as' to convert into object code.
>
> I believe that the base gcc compiler is separate from the bin-utils such as
> 'as' and 'ld' (the linker).

Check that. I think you'll find that you measured the size of the
compiler with the assembler.

> Downloading gcc tdm for Windows, these are separate download bundles. On
> Linux, this stuff is pre-installed so it's easy to think it's all the same
> thing.

No, it isn't pre-installed. Have you ever actually used Linux, or do
you just express assumptions as facts?

> When /my/ compiler does it properly, then it will be truly self-contained.
> And still be one executable.

Sure. Now tell me. What's your standard library? Let's suppose you
want to sort an array of numbers, for instance. Do you have a stdlib
function available to do that? And if so, do you include a complete
copy of your entire stdlib in every one of your output executables?

>> Then do it. Make your compiler able to target all of the above. See
>> how much ifdef mess you need.
>
> My language doesn't have ifdef. There are other ways of managing this
> switch. (Actually my current compiler for that language is interpreted. It
> supports two targets.)

Whatever you call it, you will have that switch, because platforms are
fundamentally different.

>> Plus, git shouldn't be considered an onerous requirement for a
>> developer. Go get it. Start using it.
>
> I'm doing this for fun. It's not a job to be taken seriously. And doing
> battle with other people's temperamental multi-GB applications is not my
> idea of fun.

If you aren't using git, you definitely won't be taken very seriously.
And git isn't temperamental; it's a perfectly well behaved servant
that we teach to our students in their *first day*. Why? Because it is
essential. (Actually, to be fair, they get more git workflow stuff
through their first week, but that's because we go beyond the basics
and discuss collaboration workflows, branching/merging, conflict
resolution, and more. But before the first day is over, every student
can handle the basics of creating a repository, adding files,
committing, pushing, pulling, etc.)

>> You'll have to compare like for like, and on a serious benchmark. I'm
>> not going to believe "might be 30% slower" without some actual
>> numbers.
>
>
> I've put some comments here: https://pastebin.com/hSCjNsA2 as it's getting
> way off-topic.

Not interested in clicking on a pastebin with all its ads.

>> Rhodri is right. Your naivety is so charming. You seem to genuinely
>> think that life can be that simple.
>
> And some seem to genuinely think that it needs to be that complicated just
> because there is plenty of memory to fill up.
>
> I started computing 40 years ago: you couldn't have complicated because the
> hardware wasn't up to it. Things still worked. Having more memory, more
> storage and faster processors doesn't mean complexity has to increase too.

Yeah. Things worked because IBM sold you a computer with its software,
and nobody ever expected that software to run on non-IBM hardware. Or
HP sold you a computer, and you didn't expect its software to run on
non-HP hardware. Even sharing data files wasn't easy, because one
computer used ASCII where another used EBCDIC, and they weren't
consistent with floating-point formats, and over in Japan they had
endless other differences, and nobody even thought about Chinese
characters in computers. Like I said, it's easy to solve a tiny
fraction of a problem.

ChrisA