Missing documentation part about linking program with
libpython (embedding python). Questions are:

How one can get needed CFLAGS (-I... -D...)

How one can get needed LDFLAGS (-L... -l...)

For now, applications assumes that headers located in
PREFIX/include/pythonX.Y, libraries located in
EXEC_PREFIX/lib/pythonX.Y/config

The number of google hits tells me this is still an issue.

I did not found all these Google hist.  Most of the links on the first page for “link libpython” are bug reports which are rejected by maintainers.  Related: http://mail.python.org/pipermail/python-dev/2006-February/060549.html

So, what do people link with libpython for?

Éric, this is for embedding a Python interpreter in a C/C++ application. I tend to agree that the official doc page (http://docs.python.org/extending/embedding.html) on this topic is somewhat lacking in the area of the configuration/compilation procedure. There's some info scattered around the web in tutorials, though.

So I'd say it's a valid issue.

There is (outdated, incomplete and clumsy) documentation about using distutils.sysconfig from the command-line. I'll try to work on a small patch. It will probably be Unix-only, though.

Attached patch rewrites the offending paragraphs.

Updated markup.

Antoine, this is a big improvement - LGTM.

New changeset 2c05b8a6cdd1 by Antoine Pitrou in branch '3.2':
Issue #1040439: better document how to compile and link an embedded Python interpreter.
http://hg.python.org/cpython/rev/2c05b8a6cdd1

New changeset 528abe272856 by Antoine Pitrou in branch 'default':
Issue #1040439: better document how to compile and link an embedded Python interpreter.
http://hg.python.org/cpython/rev/528abe272856

I think mentioning that you can export CFLAGS and LDFLAGS would be particularly useful.  I was able to compile some of the missing packages that were deemed 'missing' at the end of 'make' by updating setup.py and having CFLAGS and LDFLAGS point to the desired packages' directories...  Unfortunately for linux, the ability to specify *multiple* lib/ and include/ paths using this method is currently not available unless you modify setup.py.  I opened a ticket in relation to this: Issue13511 if anyone cares.

> I think mentioning that you can export CFLAGS and LDFLAGS would be
> particularly useful.  I was able to compile some of the missing
> packages that were deemed 'missing' at the end of 'make' by updating
> setup.py and having CFLAGS and LDFLAGS point to the desired packages'
> directories...

Unless I'm missing something, this is slightly off-topic for this issue,
which is about using Python as an embedded interpreter, not compiling
it. Embedding Python assumes it has already been built.

I did a review on Rietveld.

Attached patch adds the useful bits from the review I did; I hope you won’t think it’s pointless nitpicking.

> Attached patch adds the useful bits from the review I did; I hope you
> won’t think it’s pointless nitpicking.

Looks good to me.

New changeset 79e8de78abd0 by Éric Araujo in branch '3.2':
Markup improvements for the embedding CPython doc patch from #1040439
http://hg.python.org/cpython/rev/79e8de78abd0

New changeset 1cb9b8126534 by Éric Araujo in branch 'default':
Merge edits from 3.2 (#13716, #1040439, #2945, #13770, #6715)
http://hg.python.org/cpython/rev/1cb9b8126534

Is there still work to do on this issue?

> Is there still work to do on this issue?

Not for Unix, no. I don't if it's applicable to Windows.

ISTM that part of the doc specifically deals with Unix, so this issue can be closed as completed.

Windows is a different issue. Perhaps the documentation should have a new section on embedding on Windows, similarly to the "Building C and C++ Extensions on Windows" section in the "extending" documentation. Anyway, if there's interest in that, it should be a separate issue.

Is there any reason not to backport to 2.7?  (Yes, I’m volunteering.)

Éric, go ahead :)

I've now backported the 3.x update to the 2.7 docs in Issue18164 (I hadn't noticed that this issue was still open).  As Eli noted, if any updates are needed to cover Windows, a separate issue should be opened. I'm closing this one.