On Wed, May 17, 2017 at 2:52 PM, bartc <b...@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. -- https://mail.python.org/mailman/listinfo/python-list
