This patch adds pkg-config support to the python build, a python.pc file
is installed in the pkgconfig directory such that autoconf buildsystems
can trivially link against the python library.

Diff made against revision 65796

I cannot discuss about the feature itself, but the patch should
certainly use some macro ($(VERSION) ?) instead of the hardcoded "2.6".
Likewise, source files should not contain version number in their names,
or they cannot be merged between branches.

Thanks for the comments Amaury, this patch uses ${VERSION} throughout so
that it can be applied across branches.

cheers,

This version sets Libs.private for static compiles.

Any chance this will make it into the 2.6/3.0 release candidates ?

cheers,

Is there anything I can do to move this forward at all?

cheers,

The patch looks fine to me. I have however some questions to ask to
someone more used to pkgconfig:

- Do all unix-like system support pkg-config?

- Is $(LIBDIR)/pkgconfig the only choice for installing this file?

- Shouldn't this file be installed only if the pkg-config utility is
present, or if the directory $(LIBDIR)/pkgconfig already exists?

Oh, you meant for me to reply =)

- Do all unix-like system support pkg-config?

Yes. It even works on windows.

- Is $(LIBDIR)/pkgconfig the only choice for installing this file?

While pkg-config can be told to look in other directories for pc files
(via modifying the PKGCONFIGPATH env variable) it looks in
/usr/lib/pkgconfig by default, so that's where pc files should be put by
default.

- Shouldn't this file be installed only if the pkg-config utility is
present, or if the directory $(LIBDIR)/pkgconfig already exists?

Technically I suppose so, but I've not seen any package actually bother.

The patches I have made available are very similar to pkg-config
packages I've seen for many other packages.

cheers,

>> - Shouldn't this file be installed only if the pkg-config utility is
>> present, or if the directory $(LIBDIR)/pkgconfig already exists?
>
> Technically I suppose so
>

That would mean that, if you first install Python and afterwards
pkg-config, pkg-config would not work for Python, right? I'm not sure if
that would be desirable.

Hi Sol,

It's just a data file I suppose, Python should not need a dependency on
pkg-config, and neither should there be a python-pkgconfig package that
just contains the python.pc file.

I think the approach to just always install the python.pc file is the
right one.

I totally agree.

Patch looks good here.

Is there any reason in versioning Misc/python.pc, instead of versioning
it only on install?

Not that I can see, or remember. Revised patch attached. Tyop fixed as well.

Please note there seem to be some issues with svn head atm,
pyconfig.h.in and configure would seem to be out of whack with
configure.in, this patch does not include changes to those generated files.

The patch is committed in trunk (r72898) and py3k (r72899). Thanks!

Antoine: Don't use autoconf 2.63 to generate pyconfig.h.in and
configure. Use 2.61 instead (until it is agreed to switch to a newer
version).

> Antoine: Don't use autoconf 2.63 to generate pyconfig.h.in and
> configure. Use 2.61 instead (until it is agreed to switch to a newer
> version).

Oops, sorry. Are there any known issues with 2.63?

> Oops, sorry. Are there any known issues with 2.63?

Yes: it puts a carriage-return character into configure
which completely confuses subversion.

I'm puzzled how you were able to commit the generated
files; subversion should have reported an error

svn: File 'configure' has inconsistent newlines
svn: Inconsistent line ending style

See

http://mail.python.org/pipermail/python-dev/2008-November/083781.html

> Yes: it puts a carriage-return character into configure
> which completely confuses subversion.
> 
> I'm puzzled how you were able to commit the generated
> files; subversion should have reported an error
> 
> svn: File 'configure' has inconsistent newlines
> svn: Inconsistent line ending style

I did get that message (and got puzzled by it).
I worked around it by reading the file in universal newlines mode and
saving it again.

> I did get that message (and got puzzled by it).
> I worked around it by reading the file in universal newlines mode and
> saving it again.

I believe this has broken part of the configure script. There is an
ac_cr variable that is supposed to hold a sole carriage-return
character; it now holds a newline character instead. This will break
the test whether the system autoconf deals with carriage-return
characters correctly, which probably means that it may decide to use
awk to do file substitution when it should have been using /bin/sh,
or vice versa (I haven't fully understood the purpose of this test).

Ouch, unfortunately it seems my distribution doesn't package autoconf
2.61. Is there any risk in installing it from scratch?

> Ouch, unfortunately it seems my distribution doesn't package autoconf
> 2.61. Is there any risk in installing it from scratch?

I usually install it into a private location, such as ~/ac261. This is
absolutely safe.