3. Configurar o Python

3.1. Requisitos de construção

Recursos necessários para construir o CPython:

Alterado na versão 3.5: No Windows, é necessário o Visual Studio 2015 ou posterior.

Alterado na versão 3.6: Recursos selecionados do C99 agora são necessários, como funções <stdint.h> e static inline.

Alterado na versão 3.7: Suporte a threads e OpenSSL 1.0.2 agora são necessários.

Alterado na versão 3.10: OpenSSL 1.1.1 agora é necessário.

Alterado na versão 3.11: Compilador C11, suporte a IEEE 754 e NaN agora são necessários. No Windows, é necessário o Visual Studio 2017 ou posterior.

Veja também PEP 7 “Guia de estilo para código C” e PEP 11 “Suporte do CPython a plataformas”.

3.2. Arquivos gerados

Para reduzir as dependências de construção, o código-fonte do Python contém vários arquivos gerados. Comandos para regenerar todos os arquivos gerados:

make regen-all
make regen-stdlib-module-names
make regen-limited-abi
make regen-configure

O arquivo Makefile.pre.in documenta os arquivos gerados, suas entradas e ferramentas usadas para regenerá-los. Procure por alvos regen-* de make.

3.2.1. Script configure

O comando make regen-configure regera o arquivo aclocal.m4 e o script configure usando o shell script Tools/build/regen-configure.sh, o qual usa um contêiner Ubuntu para obter as mesmas versões de ferramentas e ter uma saída reproduzível.

O contêiner é opcional, o seguinte comando pode ser executado localmente:

autoreconf -ivf -Werror

Os arquivos gerados podem mudar dependendo das versões exatas do autoconf-archive, aclocal e pkg-config.

3.3. Opções de configuração

Liste todas as opções do ./configure usando:

./configure --help

Veja também o Misc/SpecialBuilds.txt na distribuição de código-fonte do Python.

3.3.1. Opções gerais

--enable-loadable-sqlite-extensions

Suporte a extensões carregáveis no módulo de extensão _sqlite (o padrão é não) do módulo sqlite3.

Veja o método sqlite3.Connection.enable_load_extension() do módulo sqlite3.

Novo na versão 3.6.

--disable-ipv6

Desabilita suporte a IPv6 (habilitado por padrão se houver suporte), veja o módulo socket.

--enable-big-digits=[15|30]

Define o tamanho em bits dos dígitos de int do Python: 15 ou 30 bits.

Por padrão, o tamanho dos dígitos é 30.

Define o PYLONG_BITS_IN_DIGIT para 15 ou 30.

Veja sys.int_info.bits_per_digit.

--with-suffix=SUFFIX

Define o sufixo do executável do Python para SUFFIX.

O sufixo padrão é .exe no Windows e macOS (executável python.exe), .js em nó Emscripten, .html em navegador Emscripten, .wasm em WASI e uma string vazia em outras plataformas (executável python).

Alterado na versão 3.11: O sufixo padrão na plataforma WASM é um entre .js, .html ou .wasm

--with-tzpath=<list of absolute paths separated by pathsep>

Seleciona o caminho de pesquisa de fuso horário padrão para zoneinfo.TZPATH. Veja a Configuração de tempo de compilação do módulo zoneinfo.

Padrão: /usr/share/zoneinfo:/usr/lib/zoneinfo:/usr/share/lib/zoneinfo:/etc/zoneinfo.

Veja o separador de caminhos os.pathsep.

Novo na versão 3.9.

--without-decimal-contextvar

Constrói o módulo de extensão _decimal usando um contexto local de thread ao invés de um contexto local de corrotina (padrão), veja o módulo decimal.

Veja decimal.HAVE_CONTEXTVAR e o módulo contextvars.

Novo na versão 3.9.

--with-dbmliborder=<list of backend names>

Substitui a ordem de verificação de backends de banco de dados para o módulo dbm

Um valor válido é uma string separada por dois pontos (:) com os nomes de backend:

  • ndbm;

  • gdbm;

  • bdb.

--without-c-locale-coercion

Desabilita a coerção de localidade C para uma localidade baseada em UTF-8 (ativada por padrão).

Não define a macro PY_COERCE_C_LOCALE.

Consulte PYTHONCOERCECLOCALE e a PEP 538.

--without-freelists

Desabilita todas as listas livres, exceto o singleton de tupla vazia.

Novo na versão 3.11.

--with-platlibdir=DIRNAME

Nome do diretório da biblioteca Python (o padrão é lib).

Fedora e SuSE usam lib64 em plataformas de 64 bits.

Veja sys.platlibdir.

Novo na versão 3.9.

--with-wheel-pkg-dir=PATH

Diretório de pacotes de wheel usados pelo módulo ensurepip (nenhum por padrão).

Algumas políticas de empacotamento de distribuição do Linux recomendam contra o empacotamento de dependências. Por exemplo, o Fedora instala pacotes wheel no diretório /usr/share/python-wheels/ e não instala o pacote ensurepip._bundled.

Novo na versão 3.10.

--with-pkg-config=[check|yes|no]

Se o configure deve usar pkg-config para detectar dependências de construção.

  • check (padrão): pkg-config é opcional

  • yes: pkg-config é obrigatório

  • no: configure não usa pkg-config mesmo quando presente

Novo na versão 3.11.

--enable-pystats

Ativa a coleta de estatísticas internas.

As estatísticas serão despejadas em um arquivo arbitrário (provavelmente único) em /tmp/py_stats/, ou C:\temp\py_stats\ no Windows. Se aquele diretório não existir, os resultados serão enviados para stdout.

Use Tools/scripts/summarize_stats.py para ler as estatísticas.

Novo na versão 3.11.

3.3.2. Opções de WebAssembly

--with-emscripten-target=[browser|node]

Define o “sabor” de construção para wasm32-emscripten.

  • browser (padrão): pré-carrega stdlib mínima, MEMFS padrão.

  • node: suporte a NODERAWFS e pthread.

Novo na versão 3.11.

--enable-wasm-dynamic-linking

Ativa o suporte de vinculação dinâmica para WASM.

A vinculação dinâmica permite dlopen. O tamanho do arquivo executável aumenta devido à eliminação limitada de código morto e recursos adicionais.

Novo na versão 3.11.

--enable-wasm-pthreads

Ativa o suporte a pthreads para WASM.

Novo na versão 3.11.

3.3.3. Opções de instalação

--prefix=PREFIX

Instala arquivos independentes de arquitetura em PREFIX. No Unix, o padrão é /usr/local.

Este valor pode ser recuperado em tempo de execução usando sys.prefix.

Como exemplo, pode-se usar --prefix="$HOME/.local/" para instalar um Python em seu diretório pessoal (home).

--exec-prefix=EPREFIX

Instala arquivos dependentes de arquitetura no EPREFIX, o padrão é --prefix.

Este valor pode ser recuperado em tempo de execução usando sys.exec_prefix.

--disable-test-modules

Não constrói nem instala módulos de teste, como o pacote test ou o módulo de extensão _testcapi (construído e instalado por padrão).

Novo na versão 3.10.

--with-ensurepip=[upgrade|install|no]

Seleciona o comando ensurepip executado na instalação do Python:

  • upgrade (padrão): executa o comando python -m ensurepip --altinstall --upgrade.

  • install: executa o comando python -m ensurepip --altinstall;

  • no: não executa ensurepip;

Novo na versão 3.6.

3.3.4. Opções de desempenho

Configurar o Python usando --enable-optimizations --with-lto (PGO + LTO) é o recomendado para melhor desempenho. O sinalizador experimental --enable-bolt também pode ser usado para melhorar o desempenho.

--enable-optimizations

Habilita a otimização guiada por perfil (PGO, do inglês Profile Guided Optimization) usando PROFILE_TASK (desabilitado por padrão).

O compilador C Clang requer o programa llvm-profdata para PGO. No macOS, o GCC também exige: o GCC é apenas um apelido para o Clang no macOS.

Desabilita também a interposição semântica no libpython se --enable-shared e GCC forem usados: adiciona -fno-semantic-interposition aos sinalizadores do compilador e do vinculador.

Nota

During the build, you may encounter compiler warnings about profile data not being available for some source files. These warnings are harmless, as only a subset of the code is exercised during profile data acquisition. To disable these warnings on Clang, manually suppress them by adding -Wno-profile-instr-unprofiled to CFLAGS.

Novo na versão 3.6.

Alterado na versão 3.10: Usa -fno-semantic-interposition no GCC.

PROFILE_TASK

Variável de ambiente usada no Makefile: argumentos de linha de comando do Python para a tarefa de geração de PGO.

Padrão: -m test --pgo --timeout=$(TESTTIMEOUT).

Novo na versão 3.8.

--with-lto=[full|thin|no|yes]

Habilita o otimização em tempo de vinculação (LTO, do inglês Link Time Optimization) em qualquer compilação (desabilitado por padrão).

O compilador C Clang requer llvm-ar para LTO (ar no macOS), bem como um vinculador compatível com LTO (ld.gold ou lld).

Novo na versão 3.6.

Novo na versão 3.11: Para usar o recurso ThinLTO, use --with-lto=thin no Clang.

Alterado na versão 3.12: Usa ThinLTO como política de otimização padrão no Clang se o compilador aceitar o sinalizador.

--enable-bolt

Habilita o uso do otimizador binário pós-vinculação BOLT (desabilitado por padrão).

BOLT faz parte do projeto LLVM, mas nem sempre está incluído em suas distribuições binárias. Este sinalizador requer que llvm-bolt e merge-fdata estejam disponíveis.

BOLT ainda é um projeto relativamente novo, então este sinalizador deve ser considerado experimental por enquanto. Como esta ferramenta opera em código de máquina, seu sucesso depende de uma combinação do ambiente de construção + os outros argumentos de configuração de otimização + a arquitetura da CPU, e nem todas as combinações são suportadas. Versões do BOLT anteriores ao LLVM 16 são conhecidas por travar o BOLT em alguns cenários. O uso do LLVM 16 ou mais recente para otimização do BOLT é fortemente incentivado.

As variáveis BOLT_INSTRUMENT_FLAGS e BOLT_APPLY_FLAGS do configure podem ser definidas para substituir o conjunto padrão de argumentos para llvm-bolt para instrumentar e aplicar dados BOLT aos binários , respectivamente.

Novo na versão 3.12.

--with-computed-gotos

Habilita “gotos” computados no laço de avaliação (habilitado por padrão em compiladores suportados).

--without-pymalloc

Desabilita o alocador de memória especializado do Python pymalloc (habilitado por padrão).

Veja também a variável de ambiente PYTHONMALLOC.

--without-doc-strings

Desabilita as strings de documentação estática para reduzir o consumo de memória (habilitado por padrão). As strings de documentação definidas em Python não são afetadas.

Não define a macro WITH_DOC_STRINGS.

Veja a macro PyDoc_STRVAR().

--enable-profiling

Habilita o perfil de código a nível C com gprof (desabilitado por padrão).

--with-strict-overflow

Adiciona -fstrict-overflow aos sinalizadores do compilador C (por padrão adicionamos -fno-strict-overflow).

3.3.5. Compilação de depuração do Python

Uma compilação de depuração é Python compilada com a opção de configuração --with-pydebug.

Efeitos de uma compilação de depuração:

  • Exibe todos os avisos por padrão: a lista de filtros de aviso padrão está vazia no módulo warnings.

  • Adiciona d a sys.abiflags.

  • Adiciona a função sys.gettotalrefcount().

  • Adiciona a opção de linha de comando -X showrefcount.

  • Adiciona a opção de linha de comando -d e a variável de ambiente PYTHONDEBUG para depurar o analisador sintático.

  • Adiciona suporte para a variável __lltrace__: habilita o rastreamento de baixo nível no laço de avaliação de bytecode se a variável estiver definida.

  • Instala ganchos de depuração nos alocadores de memória para detectar estouro de buffer e outros erros de memória.

  • Define as macros Py_DEBUG e Py_REF_DEBUG.

  • Adiciona verificações de tempo de execução: código cercado por #ifdef Py_DEBUG e #endif. Habilita as asserções assert(...) e _PyObject_ASSERT(...): não define a macro NDEBUG (veja também a configuração --with-assertions opção). Principais verificações de tempo de execução:

    • Adiciona verificações de sanidade nos argumentos da função.

    • Objetos Unicode e int são criados com sua memória preenchida com um padrão para detectar o uso de objetos não inicializados.

    • Garante que as funções que podem limpar ou substituir a exceção atual não sejam chamadas com uma exceção levantada.

    • Verifica se as funções desalocadoras não alteram a exceção atual.

    • O coletor de lixo (função gc.collect()) executa algumas verificações básicas na consistência dos objetos.

    • A macro Py_SAFE_DOWNCAST() verifica o underflow e o overflow de inteiros ao fazer o downcast de tipos largos para tipos estreitos.

Veja também o Modo de Desenvolvimento do Python e a opção de configuração --with-trace-refs.

Alterado na versão 3.8: Compilações de lançamento e compilações de depuração agora são compatíveis com ABI: definir a macro Py_DEBUG não implica mais na macro Py_TRACE_REFS (consulte a opção --with-trace-refs), que apresenta a única incompatibilidade de ABI.

3.3.6. Opções de depuração

--with-pydebug

Construção de depuração do Python: define a macro Py_DEBUG (desabilitada por padrão).

--with-trace-refs

Habilita referências de rastreamento para fins de depuração (desabilitado por padrão).

Efeitos:

  • Define a macro Py_TRACE_REFS.

  • Adiciona a função sys.getobjects().

  • Adiciona a variável de ambiente PYTHONDUMPREFS.

Esta construção não é compatível com ABI com a construção de lançamento (construção padrão) ou construção de depuração (macros Py_DEBUG e Py_REF_DEBUG).

Novo na versão 3.8.

--with-assertions

Constrói com asserções C habilitadas (o padrão é não): assert(...); e _PyObject_ASSERT(...);.

Se definido, a macro NDEBUG não é definida na variável do compilador OPT.

Veja também a opção --with-pydebug (construção de depuração) que também habilita asserções.

Novo na versão 3.6.

--with-valgrind

Habilita suporte ao Valgrind (o padrão é não).

--with-dtrace

Habilita suporte ao DTrace (o padrão é não).

Veja Instrumentando o CPython com DTrace e SystemTap.

Novo na versão 3.6.

--with-address-sanitizer

Habilita o detector de erros de memória AddressSanitizer, asan (o padrão é não).

Novo na versão 3.6.

--with-memory-sanitizer

Habilita o detector de erros de alocação do MemorySanitizer, msan (o padrão é não).

Novo na versão 3.6.

--with-undefined-behavior-sanitizer

Habilita o detector de comportamento indefinido UndefinedBehaviorSanitizer, ubsan (o padrão é não).

Novo na versão 3.6.

3.3.7. Opções da ligação

--enable-shared

Habilita a construção de uma biblioteca Python compartilhada: libpython (o padrão é não).

--without-static-libpython

Não constrói libpythonMAJOR.MINOR.a e não instala python.o (construído e habilitado por padrão).

Novo na versão 3.10.

3.3.8. Opções da biblioteca

--with-libs='lib1 ...'

Vincula bibliotecas adicionais (o padrão é não).

--with-system-expat

Constrói o módulo pyexpat usando uma biblioteca expat instalada (o padrão é não).

--with-system-libmpdec

Constrói o módulo de extensão _decimal usando uma biblioteca mpdec instalada, veja o módulo decimal (o padrão é não).

Novo na versão 3.3.

--with-readline=editline

Usa a biblioteca editline para backend do módulo readline.

Define a macro WITH_EDITLINE.

Novo na versão 3.10.

--without-readline

Não constrói o módulo readline (construído por padrão).

Não define a macro HAVE_LIBREADLINE.

Novo na versão 3.10.

--with-libm=STRING

Substitui a biblioteca matemática libm por STRING (o padrão depende do sistema).

--with-libc=STRING

Substitui a biblioteca C libc por STRING (o padrão depende do sistema).

--with-openssl=DIR

Raiz do diretório OpenSSL.

Novo na versão 3.7.

--with-openssl-rpath=[no|auto|DIR]

Define o diretório da biblioteca de tempo de execução (rpath) para bibliotecas OpenSSL:

  • no (padrão): não define o rpath;

  • auto: detecta automaticamente o rpath de --with-openssl e pkg-config;

  • DIR: define um rpath explícito.

Novo na versão 3.10.

3.3.9. Opções de segurança

--with-hash-algorithm=[fnv|siphash13|siphash24]

Seleciona o algoritmo de hash para usar em Python/pyhash.c:

  • siphash13 (padrão);

  • siphash24;

  • fnv.

Novo na versão 3.4.

Novo na versão 3.11: siphash13 é adicionado e é o novo padrão.

--with-builtin-hashlib-hashes=md5,sha1,sha256,sha512,sha3,blake2

Módulos embutidos de hash

  • md5;

  • sha1;

  • sha256;

  • sha512;

  • sha3 (com shake);

  • blake2.

Novo na versão 3.9.

--with-ssl-default-suites=[python|openssl|STRING]

Substitui a string dos conjuntos de criptografia padrão do OpenSSL:

  • python (padrão): use a seleciona preferida do Python;

  • openssl: mantém inalterados os padrões do OpenSSL;

  • STRING: usa uma string personalizada

Veja o módulo ssl.

Novo na versão 3.7.

Alterado na versão 3.10: As configurações python e STRING também definem TLS 1.2 como versão mínima do protocolo.

3.3.10. Opções do macOS

Veja Mac/README.rst.

--enable-universalsdk
--enable-universalsdk=SDKDIR

Cria uma construção binária universal. SDKDIR especifica qual SDK do macOS deve ser usado para executar a construção (o padrão é não).

--enable-framework
--enable-framework=INSTALLDIR

Cria um Python.framework em vez de uma instalação tradicional do Unix. O INSTALLDIR opcional especifica o caminho de instalação (o padrão é não).

--with-universal-archs=ARCH

Especifica o tipo de binário universal que deve ser criado. Esta opção só é válida quando --enable-universalsdk está definido.

Opções:

  • universal2;

  • 32-bit;

  • 64-bit;

  • 3-way;

  • intel;

  • intel-32;

  • intel-64;

  • all.

--with-framework-name=FRAMEWORK

Especifica o nome do framework python no macOS válido apenas quando --enable-framework está definido (padrão: Python).

3.3.11. Opções de compilação cruzada

A compilação cruzada, também conhecida como construção cruzada, pode ser usada para construir Python para outra arquitetura ou plataforma de CPU. A compilação cruzada requer um interpretador Python para a plataforma de construção. A versão do Python para construção deve corresponder à versão do Python da compilação cruzada do host.

--build=BUILD

configura para construir em BUILD, geralmente adivinhado por config.guess.

--host=HOST

faz compilação cruzada para construir programas para executar no HOST (plataforma de destino)

--with-build-python=path/to/python

caminho para construir o binário python para compilação cruzada

Novo na versão 3.11.

CONFIG_SITE=file

Uma variável de ambiente que aponta para um arquivo com substituições de configuração.

Exemplo de arquivo config.site:

# config.site-aarch64
ac_cv_buggy_getaddrinfo=no
ac_cv_file__dev_ptmx=yes
ac_cv_file__dev_ptc=no

Exemplo de compilação cruzada:

CONFIG_SITE=config.site-aarch64 ../configure \
    --build=x86_64-pc-linux-gnu \
    --host=aarch64-unknown-linux-gnu \
    --with-build-python=../x86_64/python

3.4. Sistema de Construção Python

3.4.1. Arquivos principais do sistema de construção

  • configure.ac => configure;

  • Makefile.pre.in => Makefile (criado por configure);

  • pyconfig.h (criado por configure);

  • Modules/Setup: Extensões C construídas pelo Makefile usando o shell script Module/makesetup;

3.4.2. Principais etapas de construção

  • Arquivos C (.c) são construídos como arquivos objeto (.o).

  • A static libpython library (.a) is created from objects files.

  • python.o e a biblioteca estática libpython estão vinculadas ao programa final python.

  • C extensions are built by the Makefile (see Modules/Setup).

3.4.3. Main Makefile targets

  • make: Build Python with the standard library.

  • make platform:: build the python program, but don’t build the standard library extension modules.

  • make profile-opt: build Python using Profile Guided Optimization (PGO). You can use the configure --enable-optimizations option to make this the default target of the make command (make all or just make).

  • make buildbottest: Build Python and run the Python test suite, the same way than buildbots test Python. Set TESTTIMEOUT variable (in seconds) to change the test timeout (1200 by default: 20 minutes).

  • make install: Build and install Python.

  • make regen-all: Regenerate (almost) all generated files; make regen-stdlib-module-names and autoconf must be run separately for the remaining generated files.

  • make clean: Remove built files.

  • make distclean: Same than make clean, but remove also files created by the configure script.

3.4.4. C extensions

Some C extensions are built as built-in modules, like the sys module. They are built with the Py_BUILD_CORE_BUILTIN macro defined. Built-in modules have no __file__ attribute:

>>> import sys
>>> sys
<module 'sys' (built-in)>
>>> sys.__file__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'sys' has no attribute '__file__'

Other C extensions are built as dynamic libraries, like the _asyncio module. They are built with the Py_BUILD_CORE_MODULE macro defined. Example on Linux x86-64:

>>> import _asyncio
>>> _asyncio
<module '_asyncio' from '/usr/lib64/python3.9/lib-dynload/_asyncio.cpython-39-x86_64-linux-gnu.so'>
>>> _asyncio.__file__
'/usr/lib64/python3.9/lib-dynload/_asyncio.cpython-39-x86_64-linux-gnu.so'

Modules/Setup is used to generate Makefile targets to build C extensions. At the beginning of the files, C extensions are built as built-in modules. Extensions defined after the *shared* marker are built as dynamic libraries.

The PyAPI_FUNC(), PyAPI_DATA() and PyMODINIT_FUNC macros of Include/exports.h are defined differently depending if the Py_BUILD_CORE_MODULE macro is defined:

  • Use Py_EXPORTED_SYMBOL if the Py_BUILD_CORE_MODULE is defined

  • Use Py_IMPORTED_SYMBOL otherwise.

If the Py_BUILD_CORE_BUILTIN macro is used by mistake on a C extension built as a shared library, its PyInit_xxx() function is not exported, causing an ImportError on import.

3.5. Sinalizadores do compilador e do vinculador

Options set by the ./configure script and environment variables and used by Makefile.

3.5.1. Preprocessor flags

CONFIGURE_CPPFLAGS

Value of CPPFLAGS variable passed to the ./configure script.

Novo na versão 3.6.

CPPFLAGS

(Objective) C/C++ preprocessor flags, e.g. -Iinclude_dir if you have headers in a nonstandard directory include_dir.

Both CPPFLAGS and LDFLAGS need to contain the shell’s value to be able to build extension modules using the directories specified in the environment variables.

BASECPPFLAGS

Novo na versão 3.4.

PY_CPPFLAGS

Extra preprocessor flags added for building the interpreter object files.

Default: $(BASECPPFLAGS) -I. -I$(srcdir)/Include $(CONFIGURE_CPPFLAGS) $(CPPFLAGS).

Novo na versão 3.2.

3.5.2. Compiler flags

CC

C compiler command.

Example: gcc -pthread.

CXX

C++ compiler command.

Example: g++ -pthread.

CFLAGS

C compiler flags.

CFLAGS_NODIST

CFLAGS_NODIST is used for building the interpreter and stdlib C extensions. Use it when a compiler flag should not be part of CFLAGS once Python is installed (gh-65320).

In particular, CFLAGS should not contain:

  • the compiler flag -I (for setting the search path for include files). The -I flags are processed from left to right, and any flags in CFLAGS would take precedence over user- and package-supplied -I flags.

  • hardening flags such as -Werror because distributions cannot control whether packages installed by users conform to such heightened standards.

Novo na versão 3.5.

COMPILEALL_OPTS

Options passed to the compileall command line when building PYC files in make install. Default: -j0.

Novo na versão 3.12.

EXTRA_CFLAGS

Extra C compiler flags.

CONFIGURE_CFLAGS

Value of CFLAGS variable passed to the ./configure script.

Novo na versão 3.2.

CONFIGURE_CFLAGS_NODIST

Value of CFLAGS_NODIST variable passed to the ./configure script.

Novo na versão 3.5.

BASECFLAGS

Base compiler flags.

OPT

Optimization flags.

CFLAGS_ALIASING

Strict or non-strict aliasing flags used to compile Python/dtoa.c.

Novo na versão 3.7.

CCSHARED

Compiler flags used to build a shared library.

For example, -fPIC is used on Linux and on BSD.

CFLAGSFORSHARED

Extra C flags added for building the interpreter object files.

Default: $(CCSHARED) when --enable-shared is used, or an empty string otherwise.

PY_CFLAGS

Default: $(BASECFLAGS) $(OPT) $(CONFIGURE_CFLAGS) $(CFLAGS) $(EXTRA_CFLAGS).

PY_CFLAGS_NODIST

Default: $(CONFIGURE_CFLAGS_NODIST) $(CFLAGS_NODIST) -I$(srcdir)/Include/internal.

Novo na versão 3.5.

PY_STDMODULE_CFLAGS

C flags used for building the interpreter object files.

Default: $(PY_CFLAGS) $(PY_CFLAGS_NODIST) $(PY_CPPFLAGS) $(CFLAGSFORSHARED).

Novo na versão 3.7.

PY_CORE_CFLAGS

Default: $(PY_STDMODULE_CFLAGS) -DPy_BUILD_CORE.

Novo na versão 3.2.

PY_BUILTIN_MODULE_CFLAGS

Compiler flags to build a standard library extension module as a built-in module, like the posix module.

Default: $(PY_STDMODULE_CFLAGS) -DPy_BUILD_CORE_BUILTIN.

Novo na versão 3.8.

PURIFY

Purify command. Purify is a memory debugger program.

Default: empty string (not used).

3.5.3. Sinalizadores do vinculador

LINKCC

Comando do vinculador usado para construir programas como python e _testembed.

Default: $(PURIFY) $(CC).

CONFIGURE_LDFLAGS

Value of LDFLAGS variable passed to the ./configure script.

Avoid assigning CFLAGS, LDFLAGS, etc. so users can use them on the command line to append to these values without stomping the pre-set values.

Novo na versão 3.2.

LDFLAGS_NODIST

LDFLAGS_NODIST é usado da mesma maneira que CFLAGS_NODIST. Use-o quando um sinalizador de vinculador não fizer parte de LDFLAGS depois que o Python estiver instalado (gh-65320).

In particular, LDFLAGS should not contain:

  • the compiler flag -L (for setting the search path for libraries). The -L flags are processed from left to right, and any flags in LDFLAGS would take precedence over user- and package-supplied -L flags.

CONFIGURE_LDFLAGS_NODIST

Value of LDFLAGS_NODIST variable passed to the ./configure script.

Novo na versão 3.8.

LDFLAGS

Sinalizadores do vinculador, p.ex. -Llib_dir, se você tiver bibliotecas em um diretório não padrão lib_dir.

Both CPPFLAGS and LDFLAGS need to contain the shell’s value to be able to build extension modules using the directories specified in the environment variables.

LIBS

Sinalizadores do vinculador para passar bibliotecas para o vinculador ao vincular o executável Python.

Example: -lrt.

LDSHARED

Command to build a shared library.

Default: @LDSHARED@ $(PY_LDFLAGS).

BLDSHARED

Command to build libpython shared library.

Default: @BLDSHARED@ $(PY_CORE_LDFLAGS).

PY_LDFLAGS

Default: $(CONFIGURE_LDFLAGS) $(LDFLAGS).

PY_LDFLAGS_NODIST

Default: $(CONFIGURE_LDFLAGS_NODIST) $(LDFLAGS_NODIST).

Novo na versão 3.8.

PY_CORE_LDFLAGS

Sinalizadores de vinculador usados para construir os arquivos de objeto do interpretador.

Novo na versão 3.8.