Обсуждение: Re: [NOVICE] Python verison for build in config.pl (Win32)

Matt <bsg075@gmail.com> writes:
> Attempting to build 8.5 alpha on Windows XP (MSVC 2005) with Python support.
> Path to local interpreter added to config.pl (C:\Python), but message is
> presented:

>   "Could not determine python version from path at build.pl line 38"

> Do the build scripts attempt to determine the Python version from the path
> name? Since my machine has a generic path name, is there a way to specify
> the interpreter version?

Hm, I see this in Mkvcbuild.pm:

        $solution->{options}->{python} =~ /\\Python(\d{2})/i
          || croak "Could not determine python version from path";
        $plpython->AddLibrary($solution->{options}->{python} . "\\Libs\\python$1.lib");

Apparently you need to hack that to deduce the appropriate library
pathname.  What exactly is your python path name, and is it a standard
installation pattern at all?

            regards, tom lane

On Wed, Jan 20, 2010 at 18:59, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Matt <bsg075@gmail.com> writes:
>> Attempting to build 8.5 alpha on Windows XP (MSVC 2005) with Python support.
>> Path to local interpreter added to config.pl (C:\Python), but message is
>> presented:
>
>>   "Could not determine python version from path at build.pl line 38"
>
>> Do the build scripts attempt to determine the Python version from the path
>> name? Since my machine has a generic path name, is there a way to specify
>> the interpreter version?
>
> Hm, I see this in Mkvcbuild.pm:
>
>        $solution->{options}->{python} =~ /\\Python(\d{2})/i
>          || croak "Could not determine python version from path";
>        $plpython->AddLibrary($solution->{options}->{python} . "\\Libs\\python$1.lib");
>
> Apparently you need to hack that to deduce the appropriate library
> pathname.  What exactly is your python path name, and is it a standard
> installation pattern at all?

From the OP, it's c:\python.

And yes, the python version detection is very naive, in that it
expects the default installation paths which are c:\python25 for
example. So you'll need to move your python installation to the
default location.

Or we'd welcome a patch for a smarter way to detect the version ;)

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/

Magnus Hagander <magnus@hagander.net> writes:
> Or we'd welcome a patch for a smarter way to detect the version ;)

This particular code doesn't look like it really needs to know the
*version*.  What it wants is the full pathname of the python.lib file
that goes with the python executable.  Isn't there a way to ask Python
itself for that?

            regards, tom lane

On Wed, Jan 20, 2010 at 20:24, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Or we'd welcome a patch for a smarter way to detect the version ;)
>
> This particular code doesn't look like it really needs to know the
> *version*.  What it wants is the full pathname of the python.lib file
> that goes with the python executable.  Isn't there a way to ask Python
> itself for that?

Well, it needs the version to match it to the DLL name. For python
2.6, it needs python26.dll. But yes, there should probably be some way
to ask python itself about that - that would be the non-naive method.
But as long as python is installed per default, we got it for free,
which is why it has "worked so far".



-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/

On Jan 20, 2010, at 12:27 PM, Magnus Hagander wrote:
> Well, it needs the version to match it to the DLL name. For python
> 2.6, it needs python26.dll. But yes, there should probably be some way
> to ask python itself about that - that would be the non-naive method.
> But as long as python is installed per default, we got it for free,
> which is why it has "worked so far".


[on tom's question]
IIRC, the reason you can't query Python in the same way that configure/python.m4 does is because the generated Makefile
thatsupports distutils.sysconfig does not exist in standard win32 builds. That is, AFAIK, there is no way to request
theexact path of the dll/lib file in win32. However, I'm not particularly familiar with Python on win32, so that may
notbe the case. 


Given the absence of a more precise method, I'd recommend considering something along the lines of:

Allow the user specify (config.pl?) the Python executable to build against and default to the python.exe in %PATH%.
(thismay already be the case, idk) 

Query Python for the version information and installation prefix.
python -c 'import sys; print(str(sys.version_info[0]) + str(sys.version_info[1]))'python -c 'import sys;
print(sys.prefix)'

Assume that the prefix has a normal layout, and construct the lib path from the extracted version and prefix.

2010/1/20 James William Pye <lists@jwp.name>:
> On Jan 20, 2010, at 12:27 PM, Magnus Hagander wrote:
>> Well, it needs the version to match it to the DLL name. For python
>> 2.6, it needs python26.dll. But yes, there should probably be some way
>> to ask python itself about that - that would be the non-naive method.
>> But as long as python is installed per default, we got it for free,
>> which is why it has "worked so far".
>
>
> [on tom's question]
> IIRC, the reason you can't query Python in the same way that configure/python.m4 does is because the generated
Makefilethat supports distutils.sysconfig does not exist in standard win32 builds. That is, AFAIK, there is no way to
requestthe exact path of the dll/lib file in win32. However, I'm not particularly familiar with Python on win32, so
thatmay not be the case. 
>
>
> Given the absence of a more precise method, I'd recommend considering something along the lines of:
>
> Allow the user specify (config.pl?) the Python executable to build against and default to the python.exe in %PATH%.
(thismay already be the case, idk) 
>
> Query Python for the version information and installation prefix.
>
>  python -c 'import sys; print(str(sys.version_info[0]) + str(sys.version_info[1]))'
>  python -c 'import sys; print(sys.prefix)'
>
> Assume that the prefix has a normal layout, and construct the lib path from the extracted version and prefix.

From what I can tell, it at least makes no assumptions worse than we
have now. I'm sure there are ways to break it :-), but I think there
are less than there are now.

I have applied a patch that does something like this.


-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/