Re: [gpsd-dev] [PATCH]: Link Python extensions with libpython - attempt 3

[Matt]

> Does the build already use python-config?  From your patch, it seems not.

No, further use of python-config/pkg-config might be the subject of future
changes.

> Why isn't the build using pkg-config to find python?  It seems like that
is the norm these days, and it has the advantage of being cross friendly, in
that one has to (once) set a PKG_CONFIG_PATH (and presumably you have to do
that too when you build cross).

We could use pkg-config - can we use it to find python-config too?
How do you see this all working together?

> Are you actually building cross?  Or natively under cygwin?  Why does this
even come up as an issue?  (I'm not doubting that it does; but I'd like to
understand that.)

I'm building:
1) native under Cygwin64, which compiles apart from this problem;
2) cross using Debian64-hosted Mingw{32,64}-target toolchains (close to
building, with dodgy hacks that I haven't shared yet), and
3) cross using the Mingw{32,64}-target compilers hosted under Cygwin64
(haven't got very far at all, because of Windows broken-ness).

Eventually I would like to be able to build Windows executables under
Debian, and have some third party validate that they satisfy whatever
requirements Windows executables should satisfy.

I anticipate that I will need to run some stuff under Cygwin, for example
using its scons, but execute regression tests on native (mingw target)
Win32/Win64 binaries, hosted either on Linux, Cygwin or native mingw.
Earlier, I tried to port scons and all of its dependencies to mingw, but it
became obvious that it was a very large amount lot of work, and frankly I
gave up :-/

> This patch looks like it will break the build under pkgsrc, which doesn't
provide python-config, but python2.7-config.  This is due to longstanding
issues with compatibility in python requiring installing multiple versions
at once (even before python3), and sound packaging requires that packages
depending on python be bound to the specific version used at package build
time.

The cleanest solution to this that I can see is to go hunting for Python
versions. Are there alternatives?
Using whatever Python version happens to be running the scons process is not
a valid solution.

> I'm sympathetic to what you're trying to do.  But I don't see how what's
being added is adequately portable and addresses the real issue squarely.

The underlying problem is separating the Python environment that's building
the source from that which will run the Python-linked regression test
harnesses.
That's the conceptual problem; any impacts on pkgsrc should IMHO have some
other solution, though I don't pretend to know it right now.