How to install Python package from source on Windows

[bartc]

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.

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

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

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

Here's another project, a byte-code interpreter (not for Python!):

  https://github.com/bartg/langs/blob/master/qlang/pcc64.c

Again one file. However, I've recently split this project into discrete 
compiler and interpreter, as that suits me better. So it needs a compiler:

  https://github.com/bartg/langs/blob/master/qlang/qcc64.c

Once more, a single .c source file. It should work with any C compiler; 
the only stipulation is that a file with '64' in the name needs building 
for 64-bits.

I believe these three examples are OS-neutral: they should work on 
Windows or Linux. However, mcc64 targets Windows ABI.

Note: none of these three projects is written in C. C is used as an 
intermediate language for the convenience, for portability, and for 
taking advantage of optimised compiling.

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

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.


-- 
bartc