View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000393||ascend||build-linux||public||2009-05-14 04:21||2017-02-09 16:32|
|Priority||normal||Severity||block||Reproducibility||have not tried|
|Target Version||1.0||Fixed in Version|
|Summary||0000393: pygtk install ignores INSTALL_PREFIX|
If I wanted a root install, i would be root. in all other cases,
the python wrappings install convention should be put it in $prefix/lib*/*
as usual with python. Issue a reminder and sed the correct pythonpath settings
into an scripts that need them. As it is, I cannot test pygtk interface.
|Additional Information||Substituting vars from pygtk/ascend.in into pygtk/ascend|
chmod 755 pygtk/ascend
Substituting vars from ascend-config.in into ascend-config
Substituting vars from ascend/utilities/config.h.in into ascend/utilities/config.h
scons: *** [/usr/lib64/python2.5/site-packages/ascend] /usr/lib64/python2.5/site-packages/ascend: Permission denied
scons: building terminated because of errors.
make: *** [install] Error 2
|Tags||No tags attached.|
This is a result of recent changes to directory structures, and neesd to be fixed.
The workaround is to run pygtk/ascdev to launch an 'off root' instance of ASCEND from your working directory.
Hmm, I'm not sure what is the best way to fix this. You can set INSTALL_PYTHON to the location where you want the python files to be installed, and by default this file location is set to
"%s/ascend" % distutils.sysconfig.get_python_lib()
which works well with Linux package builds as well as on Windows.
It doesn't work well if 'off root' installations, but one can set INSTALL_PYTHON for these cases, it's not too terrible.
Note that 'most' Python extensions make use of 'distutils' together with 'pycentral' or 'pysupport'; we don't want to reproduce all of the complexity of those systems if we can avoid it.
distutils takes a --prefix options quite happily-- i don't see how this should be a big deal that INSTALL_PYTHON should default to INSTALL_PREFIX if the user supplies INSTALL_PREFIX.
Now, if one _cannot tell_ whether the user supplied an INSTALL_PREFIX, something is really really broken in scons design.
Indeed... this is fixable.
distutils.sysconfig.get_python_lib([plat_specific[, standard_lib[, prefix]]])¶
Return the directory for either the general or platform-dependent library installation. If plat_specific is true, the platform-dependent include directory is returned; if false or omitted, the platform-independent directory is returned. If prefix is given, it is used as either the prefix instead of PREFIX, or as the exec-prefix instead of EXEC_PREFIX if plat_specific is true. If standard_lib is true, the directory for the standard library is returned rather than the directory for the installation of third-party extensions.
So yes, we can specify a new PREFIX.
Reminder sent to: john
Reminder sent to: john
|2009-05-14 04:21||ben||New Issue|
|2009-05-14 04:21||ben||Status||new => assigned|
|2009-05-14 04:21||ben||Assigned To||=> john|
|2009-05-14 04:21||ben||Target release||=> 0.9.6|
|2009-05-14 10:49||john||Note Added: 0000533|
|2009-05-14 14:52||john||Note Added: 0000538|
|2009-05-14 14:53||john||Priority||urgent => normal|
|2009-05-15 00:43||ben||Note Added: 0000540|
|2010-03-23 18:30||john||Target Version||=> 1.0|
|2011-04-06 16:06||john||Note Added: 0000714|
|2017-02-07 15:40||john||Note Added: 0001013|
|2017-02-09 16:32||john||Note Added: 0001014|