How to install Python package from source on Windows

[bartc]

On 17/05/2017 15:13, Chris Angelico wrote:
> On Wed, May 17, 2017 at 11:53 PM, bartc <bc at freeuk.com> wrote:

>> That's all true. But the answer is not to make it a nightmare for everyone
>> else as well as yourself. If the requirement is to get other people to build
>> your product from source for the purpose of using it or testing it (and for
>> various reasons using prebuilt binaries is not an option), then the process
>> ought to be as painless as possible.
>
> What, you mean like this?
>
> ./configure
> make
> sudo make install

No, not like that. I mean genuinely simple. Your example:

(1) Doesn't work on Windows
(2) Usually seems to involve executing 20,000 to to 30,000 lines of 
complete gobbledygook in that configuration script.

That can't possibly be justified.

One project I tried to compile comprised only a dozen modules, but still 
required nearly 1000 lines of incantations in the combined configure and 
makefile scripts to build it (which didn't work as it waS Windows).

> I think the bulk of open source software can be built using those steps.

Maybe, if within Unix or Linux.

What would happen if you were presented with a machine, of some unknown 
OS except that it's not Linux, and only had an editor, a bare compiler 
and linker to work with? Would you be completely helpless?

Suppose then the task was to run some Python, but you only had the bare 
sources: .c and .h files, and whatever .py files come as standard; where 
would you start? Would that 18,000-line configure script come in handy, 
or would it be no use at all without your usual support systems?

And you're accusing /me/ of being in a bubble!

>> Compare ease of compiling with building other C compilers from source. (And
>> actually, this can compile itself, some 17Kloc, in a few tens of
>> milliseconds.)

> In other words, it's only targeting one single CPU architecture and OS
> API.

And? My gcc installation only generates code for x86, x64. So does my 
Pelles C**. So does my lccwin**. So does my DMC (only x86). So does my 
Tiny C**. So does my MSVC2008 (x86 only). All also only generate code 
for Windows.

(** Those use separate installations to achieve those two targets. 
lccwin is one installation but uses different sets of files.)

If I wanted to build gcc for example from sources, then I need to 
download and grapple with a package containing 100,000 files, including 
tens of thousands of source files, even if I'm only interested in one 
target. /That/ is supposed to be better?

Anyway adding another target is no big deal. (I've targeted pdp10, z80, 
8086, 80386[x86] on previous compilers, sometimes as asm, sometimes as 
binary. Also C source code. I written assemblers for z80, 8051, 8086, 
80186, 80386[partial] all generating binary.)

The Win64 ABI thing is a detail. Win64 API uses 4 registers to pass 
parameters, and requires a shadow stack space; Linux uses 6 registers 
and no shadow space, and handles XMM a bit differently. I think that's it...

> Also, it emits nasm code, so if you actually want a binary, you
> can't consider this complete; the size of nasm + linker needs to be
> included.

If I download Clang for Windows, then it doesn't emit anything at all! 
In fact it can't compile anything. Because it relies on other compilers 
(gcc or MSVC, but it has to be the right one) to supply header files, 
linkers, everything it needs.

Clang is a 64MB executable.

But yes, Nasm is a poor match for my compiler, and unsatisfactory. The 
next step is to eliminate that and the need for a linker. Then this 
'mcc' project can run applications from source just like Python.

It's funny though that when /I/ stipulate third party dependencies 
[small, self-contained ones like nasm or golink], then it's bad; when 
other people do it [massive great ones like vs2015 or git] then that's good!

And I can only conclude from your comments, that CPython is also 
incomplete because it won't work without a bunch of other tools, all 
chosen to be the biggest and most elaborate there are.

  Yeah, it's not hard for a small program to produce valid
> code for one target system. How good is the resultant code? Can you
> outperform other popular compilers?

For running my language projects, it might be 30% slower than gcc-O3, 
about on a par with compilers such as DMC, lccwin, and PellesC, and 
generally faster than Tiny C. [Here I'm mixing up results from my C 
compiler and my non-C compiler; I've can't be bothered to do any 
exhaustive testing because you'll simply find another way of belittling 
my efforts.]

>> Look at the link for sqlite amalgamation I posted earlier today. On that
>> site, it says they extensively use TCL to generate some of the sources. To
>> build sqlite conventionally, would require someone to install a TCL system.
>> Their amalgamated version thankfully doesn't require that.
>>
>
> Oh, you mean like how tkinter embeds tcl? You can't possibly do that
> in a production language, can you.

No, I mean having to install some language system that is of no 
relevance whatsoever to a developer, other than being a stipulation of 
some third party add-on.

If you were paying someone by the hour to add sqlite to a project, would 
you rather they just used the amalgamated file, or would you prefer they 
spent all afternoon ******* about with TCL trying to get it to generate 
those sources?

-- 
bartc