SPECS: python-gnome-desktop.spec - use system waf and waf/__waf rp...

[Jakub Bogusz]

On Thu, Mar 27, 2008 at 04:53:03PM +0100, Bartłomiej Zimoń wrote:
> Wednesday 26 of March 2008 20:06:39 Jakub Bogusz napisał(a):
> > On Wed, Mar 26, 2008 at 09:08:34PM +0100, Bartłomiej Zimoń wrote:
> > > Wednesday 26 of March 2008 18:40:23 Jakub Bogusz napisał(a):
> > > > On Wed, Mar 26, 2008 at 07:44:53PM +0100, Bartłomiej Zimoń wrote:
> > > > > Tuesday 25 of March 2008 21:17:00 Jakub Bogusz napisał(a):
> > > > > > On Tue, Mar 25, 2008 at 09:18:44PM +0100, qboosh wrote:
> > > > > > > Author: qboosh                       Date: Tue Mar 25 20:18:44 2008 GMT
> > > > > > > Module: SPECS                         Tag: HEAD
> > > > > > > ---- Log message:
> > > > > > > - use system waf and waf/__waf rpm macros to use optflags
> > > > > > > - use waf -v build to avoid hiding compiler commands
> > > > > > 
> > > > > > Jeszcze jedno do poprawki - jak to coś przekonać, żeby nie wciskało
> > > > > > trzech ostatnich elementów do tych flag linkowania:
> > > > > > 
> > > > > > LIBPATH_PYEMBED = ['/usr/lib64', '/usr/lib/', '/usr/local/lib/', '/lib']
> > > > > > LIBPATH_PYEXT = ['/usr/lib64', '/usr/lib/', '/usr/local/lib/', '/lib']
> > > > > > 
> > > > > > Oczywiście problem ze złym katalogiem gtk-doc wynikł z użycia wafa
> > > > > > zamiast autotools.
> > > > > > 
> > > > > > 
> > > > > 
> > > > > moze to w czyms pomoze - fragment waf-1.3.2/wafadmin/Tools/python.py :
> > > > >         # according to
> > > > >         # distutils.command.build_ext.build_ext.get_libraries.__doc__
> > > > >         # this might want to be OS/2 aswell.
> > > > >         if sys.platform == 'win32' or (Py_ENABLE_SHARED is not None
> > > > >                                         and sys.platform != 'darwin'):
> > > > >                 env['LIBPATH_PYEXT'] = env['LIBPATH_PYEMBED']
> > > > >                 env['LIB_PYEXT'] = env['LIB_PYEMBED']
> > > > 
> > > > To jeszcze skąd się bierze błędne LIBPATH_PYEMBED?
> > > > 
> > > > 
> > > waf tak pobiera mniej wiecej zmienne z kompilacji pythona:
> > > $ python
> > > [...]
> > > >>> from distutils.sysconfig import get_config_var
> > > >>> v = 'prefix SO SYSLIBS SHLIBS LIBDIR LIBPL INCLUDEPY Py_ENABLE_SHARED'.split()
> > > >>> for x in v: print 'python_'+x+'=', get_config_var(x)
> > > ... 
> > > 
> > > u mnie ta operacja pokazuje:
> > >  
> > > python_prefix= /usr
> > > python_SO= .so
> > > python_SYSLIBS= -lm
> > > python_SHLIBS= -lpthread -ldl  -lutil
> > > python_LIBDIR= /usr/lib
> > > python_LIBPL= /usr/lib/python2.5/config
> > > python_INCLUDEPY= /usr/include/python2.5
> > > python_Py_ENABLE_SHARED= 1
> > > 
> > > Co widzisz u siebie jak to uruchomisz?
> > 
> > [qboosh w carme-pld ~]$ python
> > Python 2.5.2 (r252:60911, Feb 26 2008, 23:48:32)
> > [GCC 4.2.3 20080201 (release) (PLD-Linux)] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> from distutils.sysconfig import get_config_var
> > >>> v = 'prefix SO SYSLIBS SHLIBS LIBDIR LIBPL INCLUDEPY Py_ENABLE_SHARED'.split()
> > >>> for x in v: print 'python_'+x+'=', get_config_var(x)
> > ...
> > python_prefix= /usr
> > python_SO= .so
> > python_SYSLIBS= -lm
> > python_SHLIBS= -lpthread -ldl  -lutil
> > python_LIBDIR= /usr/lib64
> > python_LIBPL= /usr/lib64/python2.5/config
> > python_INCLUDEPY= /usr/include/python2.5
> > python_Py_ENABLE_SHARED= 1
> > >>>
> > 
> > 
> 
> Zbadalem to troche i przychodzi mi na mysl (brzydki) hack a la:
> 
> export BIBLIOTEKI=/usr/lib
> %waf ........
> 
> a latka na waf sprawdzalaby czy zdefiniowano zmienna ... i jesli tak to pcha to w lib.path ?
> Oczywiscie prawdziwe jest to tylko dla pythona
> 
> Przygotowac taka latke?

Bez sensu najpierw pozwalać wpisywać te błędne ścieżki, a potem
wywalać/podmieniać.
Skąd on w ogóle bierze te */lib na systemie używającym */lib64?


-- 
Jakub Bogusz    http://qboosh.pl/