If you want to push a little further. Often when you build an
extension which statically or dynamically link another library. You will need
to use the same compiler. Otherwise you might bump into ABI comptability
issues.So do you plan on "managing" which version of GCC or g++ people have and
issue a warning if they don't have the good one? How are you even supposed to
find out? Many library will expose a flag that tells you which compiler version
or range of version can be used. But no standard on this matter...Don't get me
wrong would be awesome if it worked. I just don't see a way to handle all these
contraints ...Jonathan ---- On ven., 07 août 2020 10:28:50 -0700 David
Mathog<dmat...@gmail.com> wrote ----> Unfortunately, successfully building C
libraries is way, way more > complicated than that. There are nearly as many
ways to detect and > configure C libraries as there are C libraries; tools like
pkg-config > help a bit but they're far from universal. Agreed that building a
library is more complicated. (Building a library, or anything for that matter,
which depends on boost is even worse.) Nevertheless, to do so the information
provided by pkg-config will always be required. It might not be sufficient, of
course. As for looking up this information, I am only aware of pkg-config and
pkgconf, and on many systems one is just a soft link to the other. That is also
what is used on Windows within Mingw. So it would not be unreasonable to
specify that this is the source of the information in all Posix environments.
> There can be multiple versions of libpng on the same system, with different
ABIs. Requires-External supports version ranges and pkg-config will show the
version which is installed. If Requires-External is to ever have a real usage
presumably it would have to be compatible with pkg-config in Posix
environments. That is, how would it ever work otherwise? Users who have placed
pc files in odd locations would have to modify PKG_CONFIG_PATH before running
pip or these would not be found. They would also have to specify "libname" or
"libname2", as appropriate, in some cases. > doesn't even know what compiler
the package will want to use (which > also affects which libraries are
available). I had wondered about that. In the spec it has an example:
Requires-External C which seems to be a requirement for a C compiler, but if
it does not specify which one, then the test could pass if it finds the Intel
compiler even though setup.py only knows how to build with gcc. Or vice versa.
> day, the only thing pip could do with this information is print a > slightly
nicer error message than you would get otherwise. In the case that started
this thread a simple "The igraph library is required but not installed on this
operating system" and then exit would have saved a considerable amount of time.
So while it isn't much, it is more than we have currently. > What pip *has*
done in the last few years is made it possible to pull > in packages from PyPI
when building packages from source, so you can > make your own
pkg-config-handling library and put it on PyPI and > encourage everyone to use
it instead of reinventing the wheel. Or use > more powerful build systems that
have already solved these problems, > e.g. scikit-build lets you use CMake to
build python packages. I think that is what happened this time, but there was
no test to see if the package it built could be installed where it wanted to
put it, so it failed. At least I think that is what happened. In any case, it
did pull igraph down from PyPI but the installation failed. One other point
about "Requires-External" - as described, it lacks a special case "none".
(None really means "just the python version which is running pip".) That is,
there is currently no way to distinguish between "this package has no external
requirements" and "the external requirement specification is incomplete". This
information really should be mandatory, even if it is just to tell a person
what must be installed in the OS before running pip. One can imagine a
utility analogous to "johnnydep" which would traverse a proposed package
install and verify that all the Requires-External entries are in fact
satisfied, or minimally, just list them. Pip should warn when no
"Requires-External" entries are present, and "Requires-External none" would
always suppress that warning. Regards, David Mathog -- Distutils-SIG mailing
list -- distutils-sig@python.org To unsubscribe send an email to
distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message
archived at
https://mail.python.org/archives/list/distutils-sig@python.org/message/BMLRH2JXM2B5EQAJ5NA44LGWBRTX64HY/
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at
https://mail.python.org/archives/list/distutils-sig@python.org/message/JSTXSJVVNNPT6LNTQLDWZZTKH6YRM6VF/
