| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
This ensures that `commoninstall` is completed before `bininstall` is
started when parallel builds are used (`make -j install`), and so the
`python3` symlink is only installed after all standard library modules
are installed.
Co-authored-by: Zachary Ware <zachary.ware@gmail.com>
|
|
|
|
| |
The regression was introduced with commit 5b946cada.
Restore pre gh-29696 behaviour.
|
|
|
| |
Also includes a reference shell script to implements what is documented.
|
|
|
| |
Co-authored-by: Christian Heimes <christian@python.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apply BOLT optimizations to libpython for shared builds. Most of the C
code is in libpython so it is critical to apply BOLT there fully realize
BOLT benefits.
This change also reworks how BOLT instrumentation is applied. It
effectively removes the readelf based logic added in gh-101525 and
replaces it with a mechanism that saves a copy of the pre-bolt binary
and restores that copy when necessary. This allows us to perform BOLT
optimizations without having to manually delete the output binary to
force a new bolt run.
Also:
- add a clean-bolt target for purging BOLT files and hook that up to the
clean target
- .gitignore BOLT related files
Before and after this refactor, `make` will no-op after a previous run.
Both versions should also share common make DAG deficiencies where
targets fail to trigger as often as they need to or can trigger
prematurely in certain scenarios. e.g. after this change you may need to
`rm profile-bolt-stamp` to force a BOLT run because there aren't
appropriate non-phony targets for BOLT's make target to depend on.
To make it easier to iterate on custom BOLT settings, the flags to pass
to instrumentation and application are now defined in configure and can
be overridden by passing BOLT_INSTRUMENT_FLAGS and BOLT_APPLY_FLAGS.
|
|
|
|
|
|
|
|
|
|
|
|
| |
By convention make targets that don't refer to a file have a dependency
on the fake .PHONY target/file. This ensures that these targets are
always evaluated because there is no rule to create a .PHONY file
and that will force make to think the rule is out of date and needs
to be rebuilt.
This commit consistently associates virtual targets with .PHONY by
declaring the .PHONY dependency immediately above the make rule. This
should avoid race conditions and avoidable rebuilds across multiple make
invocations.
|
|
|
| |
Also include Python 3.12 in the list of accepted versions.
|
|
|
|
| |
Signed-off-by: Zhang Na <zhangna@loongson.cn>
Co-authored-by: WANG Xuerui <git@xen0n.name>
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Set `SHELL = /bin/sh -e` to ensure that complex recipes fail on the first error rather than incorrectly reporting success.
Co-authored-by: Zachary Ware <zach@python.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several platforms don't define the static_assert macro despite having
compiler support for the _Static_assert keyword. The macro needs to be
defined since it is used unconditionally in the Python code. So it
should always be safe to define it if undefined and not in C++11 (or
later) mode.
Hence, remove the checks for particular platforms or libc versions,
and just define static_assert anytime it needs to be defined but isn't.
That way, all platforms that need the fix will get it, regardless of
whether someone specifically thought of them.
Also document that certain macOS versions are among the platforms that
need this.
The C2x draft (currently expected to become C23) makes static_assert
a keyword to match C++. So only define the macro for up to C17.
Co-authored-by: Victor Stinner <vstinner@python.org>
|
| |
|
|
|
|
|
|
| |
On content update, builds `python` and the docs. Also adds a Dockerfile that should include everything but autoconf 2.69 that's necessary to build CPython and the entire stdlib on Fedora.
Co-authored-by: Ronald Oussoren <ronaldoussoren@mac.com>
Co-authored-by: Dusty Phillips <dusty@phillips.codes>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are some warnings if build python via clang:
Parser/pegen.c:812:31: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
_PyPegen_clear_memo_statistics()
^
void
Parser/pegen.c:820:29: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
_PyPegen_get_memo_statistics()
^
void
Fix it to make clang happy.
Signed-off-by: Chenxi Mao <chenxi.mao@suse.com>
|
| |
|
|
|
|
|
|
| |
Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
Co-authored-by: Erlend E. Aasland <erlend.aasland@protonmail.com>
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
Co-authored-by: Shantanu <hauntsaninja@gmail.com>
|
|
|
|
|
|
|
|
|
| |
configure.ac (GH-100356)
In commit 254b309c801f82509597e3d7d4be56885ef94c11 a previous change to avoid linking to libpython was partially reverted for Android (and later Cygwin as well), to add back the link flags. This was applied to distutils and to python-config.sh, but not to python.pc.
Add it back to python.pc as well.
Automerge-Triggered-By: GH:gpshead
|
| |
|
|
|
|
|
| |
Fix creating install directories in `make sharedinstall` if they exist already outside `DESTDIR`. The previous make rules assumed that the directories would be created via a dependency on a rule for `$(DESTSHARED)` that did not fire if the directory did exist outside `$(DESTDIR)`.
While technically `$(DESTDIR)` could be prepended to the rule name, moving the rules for creating directories straight into the `sharedinstall` rule seems to fit the common practices better. Since the rule explicitly checks whether the individual directories exist anyway, there seems to be no reason to rely on make determining that implicitly as well.
|
| |
|
|
|
|
|
| |
(gh-101557)
gh-101282: Update BOLT --split-functions flag not to use deprecated usage
|
|
|
|
| |
MSBuild properties (GH-101523)
|
| |
|
|
|
| |
* Fix AIX build by avoiding `subprocess` during bootstrap.
|
|
|
|
|
|
| |
Windows (GH-101352)
To use this, ensure that clang support was selected in Visual Studio Installer, then set the PlatformToolset environment variable to "ClangCL" and build as normal from the command line.
It remains unsupported, but at least is possible now for experimentation.
|
| |
|
|
|
|
| |
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
Co-authored-by: Ken Jin <kenjin@python.org>
|
|
|
| |
Fixes #100340 allows -Wno-int-conversion for wasm
|
|
|
|
|
|
| |
Fix the gdbm_compat library detection logic to actually check for
-lgdbm_compat independently of the ndbm detection.
This fixes the build failure with `--with-dbmliborder=gdbm`,
and implicit fallback to ndbm with the default value.
|
| |
|
|
|
|
|
|
|
| |
CXX (#22525)
When cross-compiling, the compile/run test for -pthread always fails so -pthread
will never be automatically set without an override from the cache. ac_cv_pthread
can already be overridden, so do the same thing for ac_cv_cxx_thread.
|
|
|
|
|
| |
It has had no effect on non-macOS platforms for a long time, and has had
the non-obvious effect of invoking `pkg_config` and not setting
`-DUSING_APPLE_OS_LIBFFI` on macOS since GH-22855.
|
| |
|
| |
|
|
|
|
|
|
|
| |
in configure.ac (#99406)
Follow up to 12078e78f6e4a21f344e4eaff529e1ff3b97734f.
|
|
|
|
|
| |
Issue: #98872
Automerge-Triggered-By: GH:kumaraditya303
|
|
|
|
|
|
|
| |
computed gotos aren't enabled (GH-98265)
Keep target labels when debugging, but don't warn about lack of use.
Co-authored-by: Eryk Sun <eryksun@gmail.com>
|
|
|
|
|
|
|
|
| |
Fix a number of compile errors with GCC-12 on macOS:
1. In pylifecycle.c the compile rejects _Pragma within a declaration
2. posixmodule.c was missing a number of ..._RUNTIME macros for non-clang on macOS
3. _ctypes assumed that __builtin_available is always present on macOS
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Add COMPILEALL_OPTS variable in Makefile to override compileall
options (default: -j0) in "make install". Also merge the compileall
commands into a single command building PYC files for the all
optimization levels (0, 1, 2) at once.
Co-authored-by: Gregory P. Smith <greg@krypto.org>
|
|/ |
|
|
|
|
| |
include vendored headers (#98711)
|
| |
|
|
|
| |
Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
|
|
|
|
| |
PTHREAD_SCOPE_SYSTEM (#99085)
|
|
|
|
|
| |
This got introduced in commit 5884449539510313c826d69835829c7957c7154a
to determine if readline is already linked against curses or tinfo in
the setup.py, which is no longer present.
|
|
|
|
|
|
|
|
|
|
|
| |
The switch cases (really TARGET(opcode) macros) have been moved from ceval.c to generated_cases.c.h. That file is generated from instruction definitions in bytecodes.c (which impersonates a C file so the C code it contains can be edited without custom support in e.g. VS Code).
The code generator lives in Tools/cases_generator (it has a README.md explaining how it works). The DSL used to describe the instructions is a work in progress, described in https://github.com/faster-cpython/ideas/blob/main/3.12/interpreter_definition.md.
This is surely a work-in-progress. An easy next step could be auto-generating super-instructions.
**IMPORTANT: Merge Conflicts**
If you get a merge conflict for instruction implementations in ceval.c, your best bet is to port your changes to bytecodes.c. That file looks almost the same as the original cases, except instead of `TARGET(NAME)` it uses `inst(NAME)`, and the trailing `DISPATCH()` call is omitted (the code generator adds it automatically).
|