RFC: Replace hardcoded path with _libdir macro as done in pkgconfig.attr.

[ydario]

I have used the same macro from pkgconfig.attr.

[ydario]

In case above is not acceptable, this code can be used instead

%define py_prefix %(echo python -c "import sys; sys.stdout.write(sys.prefix)")

but I don't know if .attr files can handle above macro.

[ignatenkobrain]

on x86_64 that would be: /usr/lib64(64)? which is wrong.. do you really have very different libdir or is it %{_prefix}/lib* ?

[pmatilai]

Yup, %{_libdir} is wrong on x86_64 and technically like with %{_prefix}, there's no actual guarantee that python shares the same prefix as rpm. So I guess the really right thing to do would be querying all those different library paths out of python itself: we have %python_sitelib and %python_sitearch but nothing for the standard lib, and I'm not sure they're technically required to overlap in the way the do in eg Fedora.

Might also be that's all just being too perfect for anybodys good, and %{_prefix} be close enough for this purpose. Dunno.

The 'pyd' addition should be in a separate commit, and explained what it is. But for that too, the technically most correct solution would be fishing the extension out of python itself:

>>> import distutils.sysconfig
>>> distutils.sysconfig.get_config_vars('SHLIB_EXT')
['".so"']

[ydario]

I was not aware that x86_64 was already ending in 64.But python lib can be queried using the code in the 2nd comment, I just don't know how to insert into a .attr file.

[ydario]

I just checked SHLIB_EXT in python for OS/2, and it reports ['".dll"\r'] which is even wrong. I don't know why historically the code is compiling shared modules with PYD extension. This is a bit strange since DLL is more common and I don't see a good reason for changing it unless original porters wanted to avoid recognizing them as ordinary DLLs.

[Conan-Kudo]

@ydario But they are ordinary DLLs, so they should be marked as such...

[ydario]

yes,they are ordinary DLLs but there isn't an 'executable flag' in OS/2 (like Windows), so files can be recognized only by the extension (or inspecting the content).

[Conan-Kudo]

So then probably there's a bug in the Python port in OS/2, since it should reflect the proper extension...

[ydario]

PYD is the correct extension but probably SHLIB_EXT is not used in the build system so nobody noticed it; I'll get this variable fixed in the next build.

[pmatilai]

See https://docs.python.org/2/faq/windows.html#is-a-pyd-file-the-same-as-a-dll

So they are a bit special for Python 2, and maybe SHLIB_EXT is about something else then.

[ydario]

Special in the way they are handled by python, but from the OS point of view they are 100% DLLs. Probably they use PYD also to avoid name clash with DLL and to avoid searching the default paths.

Given that PYD is used in windows too, I think that hardcoding the extension is not an error.

[pmatilai]

Yeah it doesn't seem like an error any more than .py[oc] is, just thought there would be a configuration for this and SHLIB_EXT seemed promising. There still might be some config for it, I just dont know what that would be.