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

Jujens <jujens(a)jujens.eu <mailto:jujens@jujens.eu>> 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.

But normally, if I need to modify PYTHONPATH, I use wildcards, doesn't that work here in that case also?