On 08/06/2015 09:57 PM, Thomas Spura wrote: > Jujens <jujens@xxxxxxxxx <mailto:jujens@xxxxxxxxx>> schrieb am Sa., 1. > Aug. 2015 um 13:38 Uhr: > > On 07/31/2015 11:26 PM, Dominik 'Rathann' Mierzejewski wrote: > > Hi, > > > > On Friday, 31 July 2015 at 16:52, Jujens wrote: > >> Hi, > >> > >> I am in the process of packaging python-wsaccel > >> (https://bugzilla.redhat.com/show_bug.cgi?id=1244517). This module > >> contains C extensions and in order to launch the tests, I need to > modify > >> the python path so that the build module are found. > >> > >> The build directory to add to the path is like: > >> build/lib.%{_os}-%{_target_cpu}-%{python3_version} > >> > >> This expression works fine with i686 and x64_84. However, on armv, > >> %{_target_cpu} resolves to armv7hl whereas the folder is named > >> lib.linux-armv7l-3.4. > >> > >> Previously, I tried the %{_host} macro but it extends to i386 > instead of > >> i686 for 32 bits build. > >> > >> Is there a macro that would correctly extends in all cases > (x86_64, i686 > >> and armv7l)? If not, I will use grep to get the proper folder name. > > > > Note: the advice below is provided without looking at the code. > > > > armv7hl is correct (it's set by build environment). You could > patch the > > package's build system to use that instead of armv7l and then you > could > > use the first macro. > > > > Regards, > > Dominik > > > > Maybe there is a solution based on this. I don't know how to patch the > build system to use armv7hl. I found a `--plat-name` option in distutils > but it is only available for windows. > > The most promising option I have right know is the `--build-lib` option > which allows me to choose how the build directory is named. So instead > of relying the the default > build/lib.%{_os}-%{_target_cpu}-%{python3_version} I can choose > build/lib for instance which removes the problem of arch. > > However, there are two problem with this option: > - I don't seem to be able to use the %py2_build macro with the option. I > tried %py2_build --build-lib but rpm says that option '-' is not > recognized. Is there a way to use the macro with the option (other than > using the very ugly `eval "$(rpm --eval %%py2_build) --build-lib > %{build_lib}"`)? Or should I just not use the macro? > - `setup.py install` doesn't support `build-lib` and will always try to > install the lib from the default directory. This is not a big deal as I > can use `%{__python2} setup.py install_lib -O1 --skip-build --build-dir > %{build_lib} --install-dir %{buildroot}%{python2_sitearch}`afterwards to > complete the installation. Are you aware of a better solution? > > > --build-dir=build/lib.%{_os}-%{_target_cpu}-%{python3_version} sounds > like a good default and we are discussion on adding that by default, > which would fix some problems with noarch builds. And at the same time > this issue would be fixed. That would be a good idea I think. Adding the possiblity to pass options to the new python macros as requested in https://fedorahosted.org/fpc/ticket/557, would be great too. > > But normally, if I need to modify PYTHONPATH, I use wildcards, doesn't > that work here in that case also? > It does, that what the reviewer suggested after I uploaded my solution based on grep and is the solution I used in the package which was approved. Thanks for your input. -- Julien Enselme aka Jujens http://www.jujens.eu/ -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
