[Python-Dev] Supported make implementations
Hi, When attempting to build and run doctests for cpython on FreeBSD, I got a vague error from the default BSD make. gmake, of course, ran fine. Is GNU make the only supported make implementation? If so, did I miss that in the devguide, or should that be in there somewhere? -- Lincoln Auster They/Them ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/3HPTSDMW5ZLWK4QMN6DMKXFQ6VQ3WXGY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Supported make implementations
On 12/03/2022 06.27, Lincoln Auster wrote: Hi, When attempting to build and run doctests for cpython on FreeBSD, I got a vague error from the default BSD make. gmake, of course, ran fine. Is GNU make the only supported make implementation? If so, did I miss that in the devguide, or should that be in there somewhere? Hi, the top-level Makefile works with gmake (GNU) and bmake (BSD). Buildbot CI tests that Python builds with standard compiler and make on FreeBSD. The Makefile in Doc/ subdirectory is different. It is based on Sphinx's Makefile template. It looks like Sphinx uses GNU make features that are not supported by BSD make. Could you please open a bug at https://github.com/sphinx-doc/sphinx ? Christian ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/C465NHESPDGTZZMVZO4DPW6N4DBUSW7K/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 684: A Per-Interpreter GIL
On Thu, 10 Mar 2022, 12:12 pm Eric Snow, wrote: > > On Wed, Mar 9, 2022 at 10:58 AM Petr Viktorin wrote: > > This PEP definitely makes per-interpreter GIL sound possible :) > > > > > > “Main interpreter” should be defined. > > +1 > > > (Or maybe the term should be > > avoided instead -- always having to spell out “interpreter started by > > Py_Initialize rather than Py_NewInterpreter” might push us toward > > finding ways to avoid the special case...) > > We (me, Nick, Victor, others) have considered this in the past and > have concluded that having a distinct main interpreter is valuable. > That topic is a bit out of scope for this PEP though. > The PEP can mostly link to https://docs.python.org/3/c-api/init.html#sub-interpreter-support for the explanation of the main interpreter, and just include a partial paraphrase of those docs to give the gist of the idea. We added that info the last time we considered whether the main interpreter's "first among equals" status was necessary and decided it was. For example, something based on the first and third sentences out of the docs explanation: The “main” interpreter is the first one created when the runtime initializes. It continues to manage unique process-global responsibilities like signal handling even when other subinterpreters have been started. Cheers, Nick. > > > > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/M4IWPEJVKS6VRKLZGAFYZSXMFK6CMBD6/ Code of Conduct: http://python.org/psf/codeofconduct/
