[NOVICE] Python verison for build in config.pl (Win32)
in [PgSql]
|
Prev: Synchronization primitives (Was: Re: [HACKERS] An example of bugsfor Hot Standby)
Next: MonetDB test says that PostgreSQL often has errorsor missing results
From: Magnus Hagander on 20 Jan 2010 14:09 On Wed, Jan 20, 2010 at 18:59, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Matt <bsg075(a)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 Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 20 Jan 2010 14:27 On Wed, Jan 20, 2010 at 20:24, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Magnus Hagander <magnus(a)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 Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: James William Pye on 20 Jan 2010 16:47 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 that supports distutils.sysconfig does not exist in standard win32 builds. That is, AFAIK, there is no way to request the exact path of the dll/lib file in win32. However, I'm not particularly familiar with Python on win32, so that may 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%. (this may 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 14 Feb 2010 09:11
2010/1/20 James William Pye <lists(a)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 Makefile that supports distutils.sysconfig does not exist in standard win32 builds. That is, AFAIK, there is no way to request the exact path of the dll/lib file in win32. However, I'm not particularly familiar with Python on win32, so that may 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%. (this may 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 Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |