Avoiding TypeError deep down in setuptool#155
Conversation
The current logic only warns users about missing libraries, but still passed down those None values down to setuptools as part of the libraries sequence, which triggered failures when linking the generated modules. I still compiled the modules correctly, since my setup.cfg had the correct configuration. I'm using filter + list because Extension's libraries argument is defined as "a list of strings", but filter returns an iterator in py3. Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
|
Hello @rtobar! Thanks for updating the PR.
Comment last updated on December 11, 2018 at 10:09 Hours UTC |
|
Actually, scratch that... I didn't test thoroughly and this caused further errors down the line. I'll update my branch with the proper fixes and comment again. |
Instead of simply removing the casa_python* and boost_python* libraries from the linking process if "not found" (because they couldn't be found via the -L command-line parameter) and failing to actually load the compiled modules, let's still link with them, using a "best guess" approach in the case of boost due to its multiple possible names. If users (like myself) alter their setup.cfg with the correct paths then linking will still occur; otherwise an error will happen, maybe with a different boost library name, but users would have been warned anyway. Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
|
OK, second try... instead of removing the libraries from the list of libraries to link against, I'm now always returning the name of the library we need, using a "best guess" in the case of the boost. Using a correctly |
|
thanks! |
While compiling the python-casacore modules the compilation failed with:
This is because my casacore installation is in a non-standard directory. This happened at link time; however at compilation time the issue was not present, as I had already adjusted my
setup.cfgaccordingly. This issue instead was caused by the fact that looking for boost and casacore is done only using the-Lcommand-line parameter, but the program continues anyway if they are not found.The current logic only warns users about missing libraries, but still passed down those
Nonevalues down to setuptools as part of thelibrariesExtensionargument, which triggered failures when linking the generated modules.In the solution I'm using
filter+listbecause Extension's libraries argument is defined as "a list of strings", but filter returns an iterator in py3.cc: @JasonRuonanWang @gervandiepen