How to install Python package from source on Windows

[Chris Angelico]

On Wed, May 17, 2017 at 11:53 PM, bartc <bc at freeuk.com> wrote:
> On 17/05/2017 13:35, Rhodri James wrote:
>>
>> On 17/05/17 01:41, bartc wrote:
>
>
>> As a cross-platform developer, I find your naivity refreshing.  If only
>> life were so simple.
>>
>> When you develop code yourself, you can lay out your files however you
>> find most convenient, code to the foibles of your compiler, operating
>> system and indeed processor, and use whatever tools you choose.  The
>> moment you expect anyone else to compile your code, all of those
>> conveniences go out of the window, and things become more complex, not
>> less.  Arbitrary compilation environments require more support than
>> development, not less.
>
>
> 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

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

> Few people seem to see the point in making that effort.

Tell that to the folks behind automake. And scons. Etcetera.

>>> I'm not talking about my programs for a change. (I mentioned my compiler
>>> as an example of one that is faster than tcc but not as fast as gcc.)
>>
>>
>> You should be.  You are claiming something is easy.  Chris invited you
>> to consider how easy it isn't for code you know well.  That you keep
>> fighting shy of doing so does not speak well of you as a programmer.
>
>
> It doesn't work. I can post something that is easy to compile, but someone
> is going to say, Ah, but it doesn't do this, it doesn't do that, it doesn't
> work on X...

....... yes. That's right. Because you live in your own little bubble,
and you don't even think about it not working for other people until
someone says "it doesn't work on my system". And then you blame that
person, because it's "easy to compile" for you on your system.

You're like the people who work with eight-bit character sets because
Unicode is "hard", and everything's just so easy because there's only
one code page that matters. And it's just called "ASCII" to you, even
though it's an eight-bit code. Does this sound at all familiar?

> But setting that aside, let's take something I know a little about:
> compilers. Here's one project of mine, a C compiler:
>
>  https://github.com/bartg/langs/tree/master/bccproj
>
> The actual compiler is the 'mcc64.c' link; just one C file.
>
> (The project is not complete, but other than ending up somewhat bigger than
> its current 200KB, its still only ever going to be one file.)
>
> 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.)

Quotes from the README:

"""
(Both versions target x64 for Windows, although they should run under
Linux too.)

Note: this compiler is not guaranteed to compile any arbitrary C
programs, even within the limitations listed. It hasn't been tested on
enough sources. And the bundled headers are probably less than 5%
populated.
"""

In other words, it's only targeting one single CPU architecture and OS
API. 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. 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?

>> Yes, it's complicated.  That's the point: it *is* complicated.  You seem
>> to think that it's been made complicated for you.  It hasn't.  The hard
>> work you had to put in to compile with TCC had to be put in by other
>> people for gcc, clang, MSVC, etc.  That no one else put in the work for
>> TCC just indicates that no one else thought it was worth while.
>
>
> The hard work is because using the C language is such a minefield. It can be
> made simpler, but people tend not to do that. That just add layers of
> complexity: millions of #ifs and #ifdefs in source code, loads of macros,
> elaborate IDEs to help find your way around thousands of source files,
> scripting languages to help join all the dots because now it's no longer
> practical to do it manually.

Again, you sound like the people who complain about Unicode, and how
it's so hard to work with. Actually, the difficulties are because *the
problem space* is hard to work with (either "compiling cross-platform
code for myriad CPUs/OSes/stdlibs" or "accurately representing the
vagaries of human language"), and what you're seeing is the vastly
simplified solution. Obviously it's much easier to solve a reduced
form of the problem, just as it's far easier to solve "2*x - 5 = 0"
than it is to solve "x^4 + 3*x^3 - 10*x^2 + 2*x - 5 = 0".
Congratulations.

> 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.

ChrisA