Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

boot mpi python module name #120

Open
aminiussi opened this issue Jun 19, 2020 · 11 comments
Open

boot mpi python module name #120

aminiussi opened this issue Jun 19, 2020 · 11 comments
Assignees

Comments

@aminiussi
Copy link
Member

Right now it's mpi, which is kind of... bad.

We should at least have boost at the module path root

@aminiussi aminiussi self-assigned this Jun 19, 2020
@aminiussi
Copy link
Member Author

@xnox : Let's move this one here

@aminiussi
Copy link
Member Author

Maybe we can export both mpi (to be inline with the current name) and boost.mpi

mpi should probably be made obsolete.

@xnox
Copy link
Contributor

xnox commented Jun 22, 2020

But like in debian it has always been boost/mpi, i think it's a recent regression, or maybe you are running things out of the build-tree, rather than the install tree?

https://packages.debian.org/stretch/amd64/libboost-mpi-python1.62.0/filelist
https://packages.debian.org/sid/amd64/libboost-mpi-python1.67.0/filelist
https://packages.debian.org/sid/amd64/libboost-mpi-python1.71.0/filelist

Or is that just a debian/ubuntu thing?

@aminiussi
Copy link
Member Author

aminiussi commented Jun 22, 2020

That's probably the problem. When building from the git repository, the mpi.so file is droped in ./stage/lib/boost-python2.7/.

That should be in ./stage/lib/boost-python2.7/boost with he appropriate __init__.py.

I have no idea how to do that with bjam

@aminiussi
Copy link
Member Author

On my ubuntu box:

alainm@jarvis:~/views/boostorg/boost$ find /opt/boost-1.73.0/lib/ -name mpi.so
/opt/boost-1.73.0/lib/boost-python3.6/mpi.so
alainm@jarvis:~/views/boostorg/boost$ 

@aminiussi
Copy link
Member Author

Ok, I don't know if you had a chance to look at #112, but the issue has been discussed there.

At this point, it's a manual packaging issue.

@xnox
Copy link
Contributor

xnox commented Jun 22, 2020

Ok, I don't know if you had a chance to look at #112, but the issue has been discussed there.

At this point, it's a manual packaging issue.

Ubuntu & Debian python enable multiarch qualified names for extensions. Thus on Debian/Ubuntu compiled extensions have qualified names, such as mpi.cpython-35m-x86_64-linux-gnu.so which encode the cpython major/minor, subtype (m), and architecture.

We do create build directly per python version, and then rename the modules later.

mpi.so must not be shipped in /lib/ at all. That's not how one ships compiled python extensions.....

@aminiussi
Copy link
Member Author

Sure, but I don't think we have much control on the way it's shipped at this point.

I'm not even sure where to find the concerned bjam section.

Right now, apart from a but of documentation that says "mpi.so is in <dist>/lib/, be careful to rename it and move it in the appropriate place", I'm not sure of what can be done....

@aminiussi
Copy link
Member Author

I added some doc in 389fbf3 until we come up with something better.

@xnox
Copy link
Contributor

xnox commented Jun 22, 2020

Sigh ok. The right thing to do is to query python's configuration (by calling interpreter, or using pyconfig, or the pkg-config files) figure out how to call extensions, and where to place them, and then rename & place them appropriately.

That should do the right thing, for the right python. As things are called and places in slightly different ways depending on the python type and platform it is on.

@aminiussi
Copy link
Member Author

The right thing to do is to query python's configuration (by calling interpreter, or using pyconfig, or the pkg-config files) figure out how to call extensions, and where to place them, and then rename & place them appropriately.

If you could provide a script that does that, maybe we could discuss in issue #112 if it could be added in the distribution ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants