How to install Python package from source on Windows

Ian Kelly ian.g.kelly at gmail.com
Wed May 17 17:47:30 EDT 2017


On Wed, May 17, 2017 at 2:52 PM, bartc <bc at freeuk.com> wrote:
>
> On 17/05/2017 21:17, Michael Torrie wrote:
>>
>> On 05/17/2017 01:32 PM, bartc wrote:
>>>
>>> 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).
>>
>>
>> Well trying to edit an executable in a disassembler would look like
>> gobligook as well.
>
>
> The content of configure is high-level human readable source code. But it
is meaningless.

configure is generated code. If you want to understand what it's doing then
you should really be looking at configure.ac. But that's a whole language
of its own.

>> What a wonderful simplification!  But yes, you're essentially correct.
>> All this gobbligook figures out how to best configure the features and
>> options you require,
>
>
> Well, while we're here, why don't /you/ run configure and tell me what
the output is. Preferably in a form I can understand.
>
> Here's the input data:
>
>  OS:        Windows 7
>  Processor: Intel 64-bit
>
> Um, that's it I guess. I only need enough info to build, say, python.exe;
just something to get to first base. (I don't know what the other binary
files are or where they live.)

The input data isn't just a description of your system. It's your actual
system, including the particulars of your exact compiler and libc version
as well as optional libraries you may have installed. Generally speaking,
the way configure checks for features is by writing a short program that
uses the feature and trying to compile it.

>> determines whether your system has the required
>> compilers and libraries, figures out what source files should be
>> compiled, and calculates the order in which to build the source files.
>
>
> Yes! That's what I need!
>
> But either this information is highly classified, or nobody here actually
knows how to extract it from the output of configure or the makefile or
wherever it ends up.

configure has two primary outputs: Makefile and pyconfig.h. The latter is
actually the more important one. You can probably figure out *what* to
build and in what order just by reading Makefile.pre.in which is
essentially a template for the actual Makefile. But you're not going to get
very far without the huge number of #defines in pyconfig.h which determine
things like "is pthread.h available on this system" or "how many bytes is
the double typle on this system".

> Or, more importantly, how this list of files could be determined manually.

You're funny. :-)

> Yes. The end-result of all this might be something like:
>
>   gcc -c file1.c
>   gcc -c file2.c
>   ...
>   gcc file1.o file2.o ... -opython.exe
>
> Someone please explain why I can't just do that

Because, as has already been stated, there's no way to make such a simple
process cross-platform.



More information about the Python-list mailing list