How to install Python package from source on Windows

[bartc]

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.

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

(I have visions of you now feeding a punched card into a computer called 
Multivac occupying a cubic mile of vacuum tubes and relays... That's 
about the same degree of overkill!)

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

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

> All of things things are very important. I'd rather have this and keep
> my build times down to seconds and minutes than have to recompile all
> million lines of code for just one change.

Once again, this is not for development. It's a one-off build of a fresh 
download, so everything will need compiling anyway.

> I admit autoconf is hard to wrap my head around, hard to use as a
> programmer, and even harder to extend to handle new libraries and new
> compilers.

Has someone thought about replacing it then? I would be nervous about 
running 20000 lines of AI-generated code that manipulates my file system.

> are very nice and simple, and cross-platform.  But all of these generate
> Makefiles, which would likely be considered unnecessary gobbligook to
> you, I suspect.

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

-- 
bartc