These appeared in commit c5ae169e1. The comment on them, as well as
the presence among them of a rule for the .gitignore file itself,
indicate that the author intended these lines to remain only in their
own local working tree -- not to get committed even to their own repo,
let alone merged upstream.
They did nevertheless get committed, because it turns out that Git
takes no notice of what .gitignore says about files that it's already
tracking... for example, this .gitignore file itself.
Give effect to these lines' original intention, by deleting them. :-)
Git tip, for reference: the `.git/info/exclude` file is a handy way
to do exactly what these lines were originally intended to do. A
related handy file is `~/.config/git/ignore`. See gitignore(5),
aka `git help ignore`, for details.
https://bugs.python.org/issue37936
Automerge-Triggered-By: @zware
To embed Python into an application, a new --embed option must be
passed to "python3-config --libs --embed" to get "-lpython3.8" (link
the application to libpython). To support both 3.8 and older, try
"python3-config --libs --embed" first and fallback to "python3-config
--libs" (without --embed) if the previous command fails.
Add a pkg-config "python-3.8-embed" module to embed Python into an
application: "pkg-config python-3.8-embed --libs" includes
"-lpython3.8". To support both 3.8 and older, try "pkg-config
python-X.Y-embed --libs" first and fallback to "pkg-config python-X.Y
--libs" (without --embed) if the previous command fails (replace
"X.Y" with the Python version).
On the other hand, "pkg-config python3.8 --libs" no longer contains
"-lpython3.8". C extensions must not be linked to libpython (except
on Android, case handled by the script); this change is backward
incompatible on purpose.
"make install" now also installs "python-3.8-embed.pc".
Pgen is the oldest piece of technology in the CPython repository, building it requires various #if[n]def PGEN hacks in other parts of the code and it also depends more and more on CPython internals. This commit removes the old pgen C code and replaces it for a new version implemented in pure Python. This is a modified and adapted version of lib2to3/pgen2 that can generate grammar files compatibles with the current parser.
This commit also eliminates all the #ifdef and code branches related to pgen, simplifying the code and making it more maintainable. The regen-grammar step now uses $(PYTHON_FOR_REGEN) that can be any version of the interpreter, so the new pgen code maintains compatibility with older versions of the interpreter (this also allows regenerating the grammar with the current CI solution that uses Python3.5). The new pgen Python module also makes use of the Grammar/Tokens file that holds the token specification, so is always kept in sync and avoids having to maintain duplicate token definitions.
This change adds the necessary items to the build projects to avoid erroring out right at the start. It does not add _support_ for targeting Windows on ARM32, but is a necessary prerequisite for adding it.
gmon.out is generated when profiling turned on
Full Configuration:
./configure --prefix=$PWD/install --enable-profiling --enable-big-digits=30
--with-pydebug --with-assertions --with-valgrind
Rather than requiring the path to blurb and/or sphinx-build to be specified to the make rule, enhance the Doc/Makefile to look for each first in a virtual environment created by make venv and, if not found, look on the normal process PATH. This allows the Doc/Makefile to take advantage of an installed spinx-build or blurb and, thus, do the right thing most of the time. Also, make the directory for the venv be configurable and document the `make venv` target.
This will create a venv using the interpreter specified by the PYTHON
variable for the Makefile that also install Sphinx. Typical usage is
expected to be:
cd Doc
make venv PYTHON=../python
make html PYTHON=venv/bin/python3
