How to install Python package from source on Windows

[bartc]

On 19/05/2017 12:41, Steve D'Aprano wrote:
> On Fri, 19 May 2017 08:36 pm, bartc wrote:
>
>> Which gcc version? I can't get mine (5.1.0) to report any of these, even
>> with -Wall -Wextra -Wpedantic.
>
>
> [steve at ando langs]$ gcc --version
> gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55)

Interesting; an older version.

>
> Now perhaps you will feel a tiny glimmer of what it is like to support a
> project like Python. You can't assume that your users are running the same
> hardware and software platform you are. So you have a choice:
>
> - refuse to support users on unusual, old, or merely different platforms;
>
> - add complexity to your project in order to support more people.

I have up to 6 C compilers to hand (maybe 7 if clang now runs because of 
my VS2015, assuming it doesn't need MSBUILD too...). One more if I 
include mine, but that one will always work (I will guarantee it).

Every so often and I try and test with all of them, but usually it is 
gcc and tcc. (Currently, qcc/pcc32.c will fail on some because I'm 
letting through untruncated string constants.)

Some of the lesser compilers will have bugs; sometimes I can work around 
that, by changing the code. Sometimes I can't and that will be a limitation.

But the main aim is to have ONE single source (leaving aside the 
32/64-bit business) that works on anything as much as it can, and 
without ANY compiler-specific code. (Currently, there is one gcc-related 
macro, to do with its funny handling of callback functions in optimised 
mode for Win64.)

For qcc32.c [Q compiler] and mcc32.c [C compiler], those uploads are 
OS-neutral, since they are only doing file i/o (although mcc32 will then 
be a cross-compiler if not run on Windows).

For pcc32.c [Q interpreter], that is also OS-neutral but is a 
demonstration version, as it can't access arbitrary shared library 
functions.

For that, it would need LoadLibrary/GetProcAddr, or dlopen/dlsym. To 
make the demo version useful, a selection of essential functions (eg 
file handling) are provided by the host interpreter.


> **Which is the whole point of this argument.** You see the complexity in
> Python's build process, and claim that it's unnecessary crap.

The configure stuff certainly is. If someone could do an analysis where 
they detect the changes made by configure, then they can see how much 
work it actually did. (Or maybe it generates even more unnecessary 
stuff; I think nobody actually knows, because nobody actually wrote it.)

  After all,
> your code doesn't need anything nearly so complex!
>
> And then, almost the first time you have another person attempt to build
> your software, you learn that other users are seeing behaviour that you
> don't see on your platform.

Compiling a C file should be nothing at all. Especially of a known, 
working program.

>
> Maybe the Python core devs aren't are stupid as you have been assuming.
> Maybe there's a good reason for the complexity of Python.

Actually the majority of the C source is quite reasonable. It's when you 
get a preponderance of #includes, #defined, #ifs, #ifdefs and #errors, 
especially in headers, that it becomes taxing to try and follow.

That can happen if there are problems in compiling or linking and you 
need to delve into it, or just trying to understand it.

But I can't even get to that point. If I try and compile Modules/main.c 
I get:

  ./_decimal/libmpdec/mpdecimal.h:227:4: error: #error "define CONFIG_64 
or CONFIG_32"
     #error "define CONFIG_64 or CONFIG_32"
      ^
  ./_decimal/libmpdec/mpdecimal.h:260:5: error: unknown type name 
'mpd_ssize_t'
       mpd_ssize_t prec;   /* precision */
  ......

> You shouldn't assume that all your users are C programmers.

C is the lingua franca for open source. They don't need to understand 
the details, just what to do with the files. That means using a program 
X to turn file A into file B.

> Yes, we acknowledge that there's much improvement needed to building Python,
> especially on Windows.

The 'improvement' seems to involve making things more complicated rather 
than less.

(So I need VS2015, .NET, GIT, SVN and MSBUILD. Or maybe even more stuff, 
as I wasn't able to proceed to see what the next obstacle would be. Plus 
the minor detail of a C compiler! Presumably that's part of VS, but the 
most likely issue is that won't work from a command line.

Typing 'cl', if it's still called that, doesn't work. But there do 
appear be 3-4 versions of 'cl.exe' within the VS directories, so it 
doesn't bode well.)

-- 
bartc