[chamcham] shared object naming causes install issues

[sanjayankur31]

Hello,

I see that we look for the system suffix for the _moose.so shared object here:

https://github.com/BhallaLab/moose-core/blob/chamcham/python/setup.cmake.py#L36

While building on ppc64 on Fedora, this results in build failures because while the setup.py mentions _moose + suffix as the package data, the shared object that is compiled is still only _moose.so (without the suffix).

So, removing the bit that sets the ppc64 specific suffix fixes the build, but I'm not entirely sure if that's the right thing to do:
sanjayankur31@bf55271

You can see the failed build here, and I'm attaching the build logs too:
moose-3.1.5-1-ppc-build-log.txt

What do you think?

Cheers,
Ankur

[dilawar]

Hi Ankur,

Since we don't officially support Windows, I guess .so is the least common denominator Linux, BSD and OSX?

Can you post the output of the following on ppc64le machine?

import importlib.machinery
res = importlib.machinery.EXTENSION_SUFFIXES
print(res)

Maybe it will be a good idea to change the expression of package_data={'moose': ['_moose' + suffix]}, to package_data={'moose': ['_moose*.so']}, or to a more generic pattern?

[sanjayankur31]

Hello!

Thanks for the quick reply!

I'm afraid I don't know about WIndows either. On Linux, yes, .so should be the primary suffix.
The build log on the ppc64le machine says this:

[INFO] Suffix for python SO: .cpython-39-powerpc64le-linux-gnu.so

If the wildcard works, that would indeed be the cleanest solution.

[dilawar]

dilawar@a044beb is an attempt to fix this.

[dilawar]

I guess this can be closed now.