gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Greg Troxel
Subject: Re: [gpsd-dev] [PATCH]: Link Python extensions with libpython - attempt 3
Date: Tue, 13 Jan 2015 10:53:44 -0500
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.4 (berkeley-unix)

"Matt" <address@hidden> writes:

>> 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.

python-config is a python program that contains a #! path to the host
python.  So it seems unusable for cross, except by accident in the case
when the host prefix and the target prefix are the same.

What happens if you try to use pkg-config?  It provides libs and
includes.

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

I see building using pkg-config outputs like

  pkg-config python-2.7 --libs

and not using python-config at all.

> I'm building:
> 1) native under Cygwin64, which compiles apart from this problem;

Can you explain why a native build fails?  That doesn't immediately make
sense.

> 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.

That makes sense, eventually.
It seems that that the python/scons world isn't very cross friendly.

I wonder (a tiny bit) about switching to cmake

>> 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?

I think that is what is necessary, looking for python2.7, then
python2.6.  It certainly seems reasonable to pass in a python version in
an environment variables, perhaps via a pkg-config file.

> Using whatever Python version happens to be running the scons process is not
> a valid solution.

It's pretty good for non-cross.

> 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.

It's not just pkgsrc, it's any system that tries to cope with the python
versioning mess.


I see this as a really big job, and obviously not going to be done for
this release.  So I don't think we should do anything that's either not
long-term-best or breaks any platform in the interim.

It would be interesting to see how other programs that use python both
in the system itself and in the build process deal with cross building.
So far, I'm not really aware of successful cross building in the python
world.

Attachment: pgpbf3TN3gerp.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]