update py docs for testing and local build if CMake was used for compile

[ahbarnett]

This fixes a bunch of obsolete docs re how to build and test the Py wrapper.

We still have an issue that I cannot persuade setup.py to look in both build/ and lib/ for the finufft_dlib in the ext_modules.
Thus for the CMake user I include copying the .so over to lib/ by hand = lame.

I hope this will get obsoleted by #374 anyway.

[janden]

Thanks for doing this. I see the problem about linking to the absolute path here making it tricky to deal with both cmake and make builds. Ideally, we set libraries=['finufft'] and supply the compiler with a bunch of paths where the library could be. From the comment, it looks like the causes problems with DT_NEEDED though. I'll have to look a bit closer at this and see what can be done.

[janden]

From the comment, it looks like the causes problems with DT_NEEDED though.

Funny thing is, apparently I'm the one who wrote that comment: e64bd19

[ahbarnett]

Yeah, that's why I didn't break it. The by-hand lib move is a fix for now. Cmake --install will be a whole different place that should remain indep, I think.

…

On Wed, Dec 6, 2023 at 5:31 PM Joakim Andén ***@***.***> wrote: From the comment, it looks like the causes problems with DT_NEEDED though. Funny thing is, apparently I'm the one who wrote that comment: e64bd19 <e64bd19> — Reply to this email directly, view it on GitHub <#384 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNZRSUNMBO5DWAQJCVJX4TYIDW55AVCNFSM6AAAAABAKCMFVKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBTG44TGNZWHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- *-------------------------------------------------------------------~^`^~._.~' |\ Alex Barnett Center for Computational Mathematics, Flatiron Institute | \ http://users.flatironinstitute.org/~ahb 646-876-5942

[janden]

So I've looked into this a little bit. We can revert the change that I made and specify finufft_dlib = "finufft" and things should still be ok. The caveat is that it'll be up to the user to specify their proper LD_LIBRARY_PATH in order for things to run. Note that this is not an issue for people who install from PyPI since libfinufft.so will be included in the package (vendored in).

There is a larger question here, which relates to the install target discussion we had last week: what should the default install procedure be: local (i.e., we keep everything in the project directory and link to these libraries when needed) or global (system level, i.e., into /usr/lib, etc. or user-level into $HOME/.local/lib settable by specifying prefix). The latter assumes the user knows how to install binary libraries and relieves us of figuring out paths etc. on the fly (we'll just assume that libfinufft has been properly installed somewhere where the PATHs point us). The former puts us in this position where we have to figure out where the library (and headers) are, which can be tricky. Maybe we can continue this discussion in an issue.

[janden]

Thought about this some more and found a simpler solution (following @blackwer's trick in d993d04): set the rpath to both library locations. Now both of the following should work:

make lib
python3 -m pip install python/finufft
python3 -c "import finufft; print(finufft.__version__)"

mkdir build
(cd build && cmake .. && make)
python3 -m pip install python/finufft
python3 -c "import finufft; print(finufft.__version__)"

Should print 2.2.0dev0 in both cases. No need for LD_LIBRARY_PATH or anything. I haven't tried yet, but I think the wheel building scripts should still work as well (since Python is able to find libfinufft, auditwheel and friends should be able to as well).