# 9. API 레퍼런스

더 보기

setuptools의 신규 및 변경된 setup.py 인자

  `setuptools` 프로젝트는 `setup` 함수와 기타 API에 새로운 기능을 추가하고, API를 여러 파이썬 버전에서 일관되게 만들어서, `distutils`를 직접 사용하는 것보다 권장됩니다.

참고

이 문서는 https://setuptools.readthedocs.io/en/latest/setuptools.html 의 `setuptools` 설명서가 현재 여기에 포함된 모든 관련 정보를 독립적으로 다루기 전까지만 보존됩니다.

## 9.1. `distutils.core` — 핵심 Distutils 기능

`distutils.core` 모듈은 Distutils를 사용하기 위해 설치해야 하는 유일한 모듈입니다. `setup()`(설치 스크립트에서 호출됩니다)을 제공합니다. `distutils.dist.Distribution`과 `distutils.cmd.Command` 클래스를 간접적으로 제공합니다.

`distutils.core.``setup`(arguments)

  Distutils 메서드에서 요청할 수 있는 대부분의 작업을 수행하는 기본 만능 함수.

  setup 함수는 많은 수의 인자를 취합니다. 이는 다음 표에 나와 있습니다.

  인자 이름 | 값 | 형
  --- | --- | ---
  name | 패키지 이름 | 문자열
  version | 패키지의 버전 번호; `distutils.version`을 참조하십시오 | 문자열
  description | 패키지를 설명하는 한 줄 | 문자열
  long_description | 패키지에 대한 자세한 설명 | 문자열
  author | 패키지 저자의 이름 | 문자열
  author_email | 패키지 저자의 이메일 주소 | 문자열
  maintainer | 저자와 다르다면, 현재 관리자의 이름. 관리자가 제공되면 distutils는, 이것을 `PKG-INFO`에서 저자로 사용함에 유의하십시오. | 문자열
  maintainer_email | 작성자와 다르다면, 현재 관리자의 이메일 주소 | 문자열
  url | 패키지의 URL (홈페이지) | 문자열
  download_url | 패키지를 다운로드하기 위한 URL | 문자열
  packages | distutils가 다룰 파이썬 패키지 리스트 | 문자열 리스트
  py_modules | distutils가 다룰 파이썬 모듈 리스트 | 문자열 리스트
  scripts | 빌드하고 설치할 독립 실행형 스크립트 파일 리스트 | 문자열 리스트
  ext_modules | 빌드할 파이썬 확장 리스트 | `distutils.core.Extension`의 인스턴스 리스트
  classifiers | 패키지 범주 리스트 | 문자열 리스트; 유효한 분류자는 PyPI에 나열됩니다.
  distclass | 사용할 `Distribution` 클래스 | `distutils.core.Distribution`의 서브 클래스
  script_name | setup.py 스크립트의 이름 - 기본값은 `sys.argv[0]` | 문자열
  script_args | 설정 스크립트에 제공할 인자 | 문자열 리스트
  options | 설정 스크립트의 기본 옵션 | 딕셔너리
  license | 패키지 라이선스 | 문자열
  keywords | 설명 메타 데이터, PEP 314를 참조하십시오 | 문자열 리스트나 쉼표로 구분된 문자열
  platforms |  | 문자열 리스트나 쉼표로 구분된 문자열
  cmdclass | 명령 이름에서 `Command` 서브 클래스로의 매핑 | 딕셔너리
  data_files | 설치할 데이터 파일 리스트 | 리스트
  package_dir | 패키지에서 디렉터리 이름으로의 매핑 | 딕셔너리

`distutils.core.``run_setup`(script_name[, script_args=None, stop_after='run'])

  다소 통제된 환경에서 설정 스크립트를 실행하고, 작업을 구동하는 `distutils.dist.Distribution` 인스턴스를 반환합니다. 이는 (script에서 `setup()`으로 키워드 인자로 전달된) 배포 메타 데이터나, 구성 파일이나 명령 줄의 내용을 찾아야 하는 경우 유용합니다.

  script_name은 `exec()`로 읽고 실행할 파일입니다. 호출 기간에 `sys.argv[0]`은 script로 대체됩니다. script_args는 문자열 리스트입니다; 제공되면 `sys.argv[1:]`은 호출 기간에 script_args로 대체됩니다.

  stop_after는 `setup()`에게 처리 중지 시기를 알려줍니다. 가능한 값:

  값 | 설명
  --- | ---
  init | `Distribution` 인스턴스가 생성되고 `setup()`에 대한 키워드 인자로 채워진 후 중지합니다
  config | 구성 파일이 구문 분석된 (그리고 해당 데이터가 `Distribution` 인스턴스에 저장된) 후 중지합니다
  commandline | 명령 줄(`sys.argv[1:]`이나 script_args)이 구문 분석된 (그리고 데이터가 `Distribution` 인스턴스에 저장된) 후 중지합니다
  run | 모든 명령이 실행된 후 중지합니다 (`setup()`이 일반적인 방법으로 호출된 것과 같습니다). 이것이 기본값입니다.

또한, `distutils.core` 모듈은 다른 곳에 있는 여러 클래스를 노출합니다.

- `distutils.extension`의 `Extension`

- `distutils.cmd`의 `Command`

- `distutils.dist`의 `Distribution`

이들 각각에 대한 간략한 설명은 다음과 같지만, 전체 레퍼런스는 관련 모듈을 참조하십시오.

class `distutils.core.``Extension`

  Extension 클래스는 설정 스크립트의 단일 C나 C++ 확장 모듈을 기술합니다. 생성자에서 다음 키워드 인자를 받아들입니다:

  인자 이름 | 값 | 형
  --- | --- | ---
  name | 모든 패키지를 포함하여, 확장의 전체 이름 — 즉 파일명이나 경로명이 아니라, 점으로 구분된 파이썬 이름 | 문자열
  sources | 이식성을 위해 유닉스 형식의 (슬래시로 구분된), 배포 루트(설치 스크립트가 있는 위치)에 상대적인, 소스 파일명 리스트. 소스 파일은 C, C++, SWIG (.i), 플랫폼별 리소스 파일 또는 build_ext 명령이 파이썬 확장의 소스로 인식하는 다른 모든 것일 수 있습니다. | 문자열 리스트
  include_dirs | C/C++ 헤더 파일을 검색할 디렉터리 리스트 (이식성을 위해 유닉스 형식으로) | 문자열 리스트
  define_macros | 정의할 매크로 리스트; 각 매크로는 2-튜플 `(name, value)`를 사용하여 정의됩니다, 여기서 value는 정의할 문자열이거나 특정 값없이 정의하는 `None`입니다 (소스의 `#define FOO`나 유닉스 C 컴파일러 명령 줄의 `-DFOO`와 동등합니다). | 튜플 리스트
  undef_macros | 명시적으로 정의 해제(undef)할 매크로 리스트 | 문자열 리스트
  library_dirs | 링크 시점에 C/C++ 라이브러리를 검색할 디렉터리 리스트 | 문자열 리스트
  libraries | 링크할 라이브러리 이름 (파일명이나 경로가 아닙니다) 리스트 | 문자열 리스트
  runtime_library_dirs | 실행 시점에 C/C++ 라이브러리를 검색할 디렉터리 리스트 (공유 확장의 경우, 확장이 로드될 때입니다) | 문자열 리스트
  extra_objects | 링크할 추가 파일 리스트 (예를 들어 ‘sources’가 암시하지 않는 오브젝트 파일, 명시적으로 지정해야 하는 정적 라이브러리, 바이너리 리소스 파일 등) | 문자열 리스트
  extra_compile_args | ‘sources’에 있는 소스 파일을 컴파일할 때 사용할 추가 플랫폼과 컴파일러별 정보. 명령 줄이 의미가 있는 플랫폼과 컴파일러의 경우, 일반적으로 명령 줄 인자 리스트이지만, 다른 플랫폼의 경우 어떤 것이 든 될 수 있습니다. | 문자열 리스트
  extra_link_args | 확장을 만들기 위해 (또는 새로운 정적 파이썬 인터프리터를 만들기 위해) 오브젝트 파일을 함께 링크할 때 사용할 추가 플랫폼과 컴파일러별 정보. ‘extra_compile_args’와 유사한 해석. | 문자열 리스트
  export_symbols | 공유 확장에서 내보낼 심볼 리스트. 모든 플랫폼에서 사용되지는 않으며, 일반적으로 정확히 하나의 심볼(`init` + 확장 이름)을 내보내는 파이썬 확장에는 필요하지 않습니다. | 문자열 리스트
  depends | 확장이 의존하는 파일 리스트 | 문자열 리스트
  language | 확장 언어(즉 `'c'`, `'c++'`, `'objc'`). 제공되지 않으면 소스 확장자에서 감지됩니다. | 문자열
  optional | 확장의 빌드 실패가 빌드 프로세스를 중단하지 않고, 단순히 확장을 건너뛰도록 지정합니다. | 불리언

  버전 3.8에서 변경: 유닉스에서, 안드로이드와 Cygwin을 제외하고 C 확장은 더는 libpython에 링크되지 않습니다.

class `distutils.core.``Distribution`

  `Distribution`은 파이썬 소프트웨어 패키지를 빌드, 설치 및 패키징하는 방법을 기술합니다.

  Distribution 생성자에서 허용되는 키워드 인자 리스트는 `setup()` 함수를 참조하십시오. `setup()`은 Distribution 인스턴스를 만듭니다.

  버전 3.7에서 변경: `Distribution`은 이제 `classifiers`, `keywords` 및 `platforms` 필드가 리스트나 문자열로 지정되지 않으면 경고합니다.

class `distutils.core.``Command`

  `Command` 클래스(또는 서브 클래스 중 하나의 인스턴스)는 단일 distutils 명령을 구현합니다.

## 9.2. `distutils.ccompiler` — CCompiler 베이스 클래스

이 모듈은 `CCompiler` 클래스를 위한 추상 베이스 클래스를 제공합니다. `CCompiler` 인스턴스는 단일 프로젝트를 빌드하는 데 필요한 모든 컴파일과 링크 단계에 사용할 수 있습니다. 컴파일러 옵션을 설정하는 메서드가 제공됩니다 — 매크로 정의, 인클루드 디렉터리, 링크 경로, 라이브러리 등.

이 모듈은 다음과 같은 함수를 제공합니다.

`distutils.ccompiler.``gen_lib_options`(compiler, library_dirs, runtime_library_dirs, libraries)

  라이브러리 디렉터리를 검색하고 특정 라이브러리와 링크하기 위한 링커 옵션을 생성합니다. libraries와 library_dirs는 각각 라이브러리 이름(파일명이 아닙니다)과 검색 디렉터리 리스트입니다. 일부 컴파일러에서 사용하기에 적합한 명령 줄 옵션 리스트를 반환합니다 (전달된 두 포맷 문자열에 따라 다릅니다).

`distutils.ccompiler.``gen_preprocess_options`(macros, include_dirs)

  최소 두 가지 유형의 컴파일러에서 사용되는 C 전처리기 옵션(`-D`, `-U`, `-I`)을 생성합니다: 일반적인 유닉스 컴파일러와 Visual C++. macros는 일반적으로 1-튜플 또는 2-튜플 리스트입니다. 여기서 `(name,)`은 정의 해제 (`-U`) 매크로 name을 의미하고, `(name, value)`는 name을 value로 정의하는 (`-D`) 매크로를 의미합니다. include_dirs는 헤더 파일 검색 경로에 추가할 디렉터리 이름 리스트입니다 (`-I`). 유닉스 컴파일러나 Visual C++에 적합한 명령 줄 옵션 리스트를 반환합니다.

`distutils.ccompiler.``get_default_compiler`(osname, platform)

  주어진 플랫폼에 사용할 기본 컴파일러를 파악합니다.

  osname은 표준 파이썬 OS 이름 (즉, `os.name`에서 반환된 이름) 중 하나여야 하며 platform은 해당 플랫폼에서 `sys.platform`이 반환하는 일반 값이어야 합니다.

  매개 변수가 제공되지 않으면 기본값은 `os.name`과 `sys.platform`입니다.

`distutils.ccompiler.``new_compiler`(plat=None, compiler=None, verbose=0, dry_run=0, force=0)

  제공된 플랫폼/컴파일러 조합에 대한 어떤 CCompiler 서브 클래스의 인스턴스를 생성하는 팩토리 함수. plat의 기본값은 `os.name`이고 (예를 들어 `'posix'`, `'nt'`), compiler의 기본값은 해당 플랫폼의 기본 컴파일러입니다. 현재 `'posix'`와 `'nt'` 만 지원되며, 기본 컴파일러는 “전통적인 유닉스 인터페이스”(`UnixCCompiler` 클래스)와 Visual C++(`MSVCCompiler` 클래스)입니다. 윈도우에서 유닉스 컴파일러 객체를, 유닉스에서 Microsoft 컴파일러 객체를 요청하는 것도 완벽히 가능함에 유의하십시오 — compiler에 대한 값을 제공하면, plat은 무시됩니다.

`distutils.ccompiler.``show_compilers`()

  사용 가능한 컴파일러 리스트를 인쇄합니다 (build, build_ext, build_clib에 대한 `--help-compiler` 옵션에서 사용됩니다).

class `distutils.ccompiler.``CCompiler`([verbose=0, dry_run=0, force=0])

  추상 베이스 클래스 `CCompiler`는 실제 컴파일러 클래스에서 구현해야 하는 인터페이스를 정의합니다. 이 클래스에는 여러 컴파일러 클래스에서 사용하는 유틸리티 메서드도 있습니다.

  컴파일러 추상화 클래스의 기본 개념은 단일 프로젝트를 빌드하는 모든 컴파일/링크 단계에 각 인스턴스를 사용할 수 있다는 것입니다. 따라서, 모든 컴파일과 링크 단계에 공통적인 어트리뷰트는 컴파일러 인스턴스의 어트리뷰트입니다 — 인클루드 디렉터리, 정의할 매크로, 링크할 라이브러리 등. 개별 파일이 처리되는 방식의 가변성을 허용하기 위해, 이러한 어트리뷰트의 대부분은 컴파일 별 또는 링크 별로 달라질 수 있습니다.

  각 서브 클래스의 생성자는 Compiler 객체의 인스턴스를 만듭니다. 플래그는 verbose (상세한 출력을 표시합니다), dry_run (실제로 단계를 실행하지 않습니다) 및 force(종속성과 관계없이, 모든 것을 다시 빌드합니다)입니다. 이러한 모든 플래그의 기본값은 `0`(꺼짐)입니다. `CCompiler`나 서브 클래스 중 하나를 직접 인스턴스 화하고 싶지는 않을 것임에 유의하십시오 - 대신 `distutils.CCompiler.new_compiler()` 팩토리 함수를 사용하십시오.

  다음 메서드를 사용하면 Compiler 클래스의 인스턴스에 대한 컴파일러 옵션을 수동으로 변경할 수 있습니다.

  `add_include_dir`(dir)

    헤더 파일을 검색할 디렉터리 리스트에 dir을 추가합니다. 컴파일러는 `add_include_dir()`에 대한 연속적인 호출에 의해 제공되는 순서대로 디렉터리를 검색하도록 지시받습니다.

  `set_include_dirs`(dirs)

    검색할 디렉터리 리스트를 dirs(문자열 리스트)로 설정합니다. `add_include_dir()`에 대한 이전 호출을 무시합니다; `add_include_dir()`에 대한 후속 호출은 `set_include_dirs()`에 전달된 리스트에 추가됩니다. 이는 컴파일러가 기본적으로 검색할 수 있는 표준 인클루드 디렉터리 리스트에 영향을 주지 않습니다.

  `add_library`(libname)

    이 컴파일러 객체에 의해 구동되는 모든 링크에 포함될 라이브러리 리스트에 libname을 추가합니다. libname은 라이브러리를 포함하는 파일의 이름이 *아니라*, 라이브러리 자체의 이름이어야 합니다: 실제 파일명은 링커, 컴파일러 또는 컴파일러 클래스(플랫폼에 따라 다릅니다)에 의해 유추됩니다.

    링커는 `add_library()` 및/또는 `set_libraries()`에 제공된 순서대로 라이브러리에 링크하도록 지시받습니다. 라이브러리 이름을 중복하는 것은 완벽하게 유효합니다; 링커는 언급된 횟수만큼 라이브러리에 링크하도록 지시받습니다.

  `set_libraries`(libnames)

    이 컴파일러 객체에 의해 구동되는 모든 링크에 포함될 라이브러리 리스트를 libnames(문자열 리스트)로 설정합니다. 이것은 링커가 기본적으로 포함할 수 있는 표준 시스템 라이브러리에 영향을 주지 않습니다.

  `add_library_dir`(dir)

    `add_library()`와 `set_libraries()`에 지정된 라이브러리를 검색할 디렉터리 리스트에 dir을 추가합니다. 링커는 `add_library_dir()` 및/또는 `set_library_dirs()`에 제공된 순서대로 라이브러리를 검색하도록 지시받습니다.

  `set_library_dirs`(dirs)

    라이브러리 검색 디렉터리 리스트를 dirs(문자열 리스트)로 설정합니다. 이것은 링커가 기본적으로 검색할 수 있는 표준 라이브러리 검색 경로에 영향을 주지 않습니다.

  `add_runtime_library_dir`(dir)

    실행 시간에 공유 라이브러리를 검색할 디렉터리 리스트에 dir을 추가합니다.

  `set_runtime_library_dirs`(dirs)

    실행 시간에 공유 라이브러리를 검색할 디렉터리 리스트를 dirs(문자열 리스트)로 설정합니다. 이는 실행 시간 링커가 기본적으로 검색할 수 있는 표준 검색 경로에 영향을 주지 않습니다.

  `define_macro`(name[, value=None])

    이 컴파일러 객체에 의해 구동되는 모든 컴파일에 대한 전처리기 매크로를 정의합니다. 선택적 매개 변수 value는 문자열이어야 합니다; 제공되지 않으면, 매크로는 명시적 값없이 정의되며 정확한 결과는 사용된 컴파일러에 따라 다릅니다.

  `undefine_macro`(name)

    이 컴파일러 객체에 의해 구동되는 모든 컴파일에 대한 전처리기 매크로를 정의 해제합니다. 같은 매크로가 `define_macro()`에 의해 정의되고 `undefine_macro()`에 의해 정의 해제되면 마지막 호출이 우선합니다 (여러 재정의나 정의 해제를 포함합니다). 매크로가 컴파일 별로 (즉, `compile()` 호출에서) 재정의/정의 해제되면, 이것이 우선합니다.

  `add_link_object`(object)

    이 컴파일러 객체에 의해 구동되는 모든 링크에 포함될 오브젝트 파일(또는 유사물들, 가령 명시적으로 명명된 라이브러리 파일이나 “리소스 컴파일러”의 출력) 리스트에 object를 추가합니다.

  `set_link_objects`(objects)

    objects에 대한 모든 링크에 포함될 오브젝트 파일(또는 유사물들) 리스트를 설정합니다. 이는 링커가 기본적으로 포함할 수 있는 표준 오브젝트 파일에는 영향을 주지 않습니다 (가령 시스템 라이브러리).

  다음 메서드는 GNU autoconf와 유사한 일부 기능을 제공하는 컴파일러 옵션의 자동 감지 방법을 구현합니다.

  `detect_language`(sources)

    주어진 파일이나 파일 리스트의 언어를 감지합니다. 인스턴스 어트리뷰트 `language_map`(딕셔너리)과 `language_order`(리스트)를 사용하여 작업을 수행합니다.

  `find_library_file`(dirs, lib[, debug=0])

    지정된 디렉터리 리스트에서 정적 또는 공유 라이브러리 파일 lib를 검색하고 해당 파일의 전체 경로를 반환합니다. debug가 참이면, 디버깅 버전을 찾습니다 (현재 플랫폼에서 의미가 있다면). 지정된 디렉터리 어디에서도 lib를 찾을 수 없으면 `None`을 반환합니다.

  `has_function`(funcname[, includes=None, include_dirs=None, libraries=None, library_dirs=None])

    현재 플랫폼에서 funcname이 지원되는지를 나타내는 불리언을 반환합니다. 선택적 인자는 추가 인클루드 파일과 경로 및 라이브러리와 경로를 제공하여 컴파일 환경을 보강하는 데 사용할 수 있습니다.

  `library_dir_option`(dir)

    라이브러리 검색 디렉터리 리스트에 dir을 추가하는 컴파일러 옵션을 반환합니다.

  `library_option`(lib)

    공유 라이브러리나 실행 파일에 링크되는 라이브러리 리스트에 lib를 추가하는 컴파일러 옵션을 반환합니다.

  `runtime_library_dir_option`(dir)

    실행 시간 라이브러리 검색 디렉터리 리스트에 dir을 추가하는 컴파일러 옵션을 반환합니다.

  `set_executables`(**args)

    다양한 컴파일 단계를 수행하기 위해 실행할 실행 파일(및 옵션)을 정의합니다. 여기에 지정할 수 있는 정확한 실행 파일 집합은 컴파일러 클래스(‘executables’ 클래스 어트리뷰트를 통해)에 따라 다르지만, 대부분은 다음을 갖습니다:

    어트리뷰트 | 설명
    --- | ---
    compiler | C/C++ 컴파일러
    linker_so | 공유 오브젝트와 라이브러리를 만드는 데 사용되는 링커
    linker_exe | 바이너리 실행 파일을 만드는 데 사용되는 링커
    archiver | 정적 라이브러리 생성기

    명령 줄이 있는 플랫폼(유닉스, DOS/윈도우)에서, 이들 각각은 실행 파일 이름과 (선택적인) 인자 리스트로 분할될 문자열입니다. (문자열 분할은 유닉스 셸이 작동하는 방식과 유사하게 수행됩니다: 단어는 스페이스로 구분되지만, 따옴표와 역 슬래시는 이를 무시할 수 있습니다. `distutils.util.split_quoted()`를 참조하십시오.)

  다음 메서드는 빌드 프로세스의 단계를 호출합니다.

  `compile`(sources[, output_dir=None, macros=None, include_dirs=None, debug=0, extra_preargs=None, extra_postargs=None, depends=None])

    하나 이상의 소스 파일을 컴파일합니다. 오브젝트 파일을 생성합니다 (예를 들어 `.c` 파일을 `.o` 파일로 변환합니다).

    sources는 C/C++ 파일과 같은 파일명 리스트이어야 하지만, 실제로는 특정 컴파일러와 컴파일러 클래스에서 처리할 수 있는 모든 것입니다 (예를 들어 `MSVCCompiler`는 sources에 있는 리소스 파일을 처리할 수 있습니다). sources의 소스 파일명 당 하나씩 오브젝트 파일명 리스트를 반환합니다. 구현에 따라, 모든 소스 파일이 반드시 컴파일되는 것은 아니지만, 해당하는 모든 오브젝트 파일명이 반환됩니다.

    output_dir이 제공되면, 원래 경로 구성 요소를 유지하면서 오브젝트 파일이 그 아래에 배치됩니다. 즉, `foo/bar.c`는 일반적으로 `foo/bar.o`로 컴파일됩니다 (유닉스 구현의 경우); output_dir이 build이면, `build/foo/bar.o`로 컴파일됩니다.

    주어지면, macros는 매크로 정의 리스트이어야 합니다. 매크로 정의는 `(name, value)` 2-튜플이나 `(name,)` 1-튜플입니다. 전자는 매크로를 정의합니다; 값이 `None`이면, 매크로는 명시적 값없이 정의됩니다. 1-튜플인 경우는 매크로 정의를 해제합니다. 나중에 오는 정의/재정의/정의 해제가 우선합니다.

    주어지면, include_dirs는 문자열 리스트이어야 하며, 이 컴파일에 대해서만 기본 인클루드 파일 검색 경로에 추가할 디렉터리입니다.

    debug는 불리언입니다; 참이면 컴파일러는 오브젝트 파일 내에 (또는 함께) 디버그 심볼을 출력하도록 지시받습니다.

    extra_preargs와 extra_postargs는 구현에 따라 다릅니다. 명령 줄 개념이 있는 플랫폼(예를 들어 유닉스, DOS/윈도우)에서는, 대부분 문자열 리스트일 가능성이 높습니다: 컴파일러 명령 줄 앞에 추가하거나 뒤에 붙일 추가 명령 줄 인자. 다른 플랫폼에서는, 구현 클래스 설명서를 참조하십시오. 어쨌든, 그것들은 추상 컴파일러 프레임워크가 바라는 대로 되지 않는 경우를 위한 탈출용 비상구로 의도되었습니다.

    주어지면, depends는 모든 대상이 의존하는 파일명 리스트입니다. 소스 파일이 의존하는 파일보다 오래되었으면, 소스 파일이 다시 컴파일됩니다. 이는 종속성 추적을 지원하지만, 대략적인 세분성으로만 가능합니다.

    실패 시 `CompileError`를 발생시킵니다.

  `create_static_lib`(objects, output_libname[, output_dir=None, debug=0, target_lang=None])

    여러 가지를 함께 링크하여 정적 라이브러리 파일을 만듭니다. “여러 가지”는 objects로 제공되는 오브젝트 파일 리스트, `add_link_object()` 및/또는 `set_link_objects()`에 제공되는 추가 오브젝트 파일, `add_library()` 및/또는 `set_libraries()`에 제공되는 라이브러리, libraries(있다면)로 제공되는 라이브러리로 구성됩니다.

    output_libname은 파일명이 아닌 라이브러리 이름이어야 합니다; 파일명은 라이브러리 이름에서 유추됩니다. output_dir은 라이브러리 파일이 저장될 디렉터리입니다.

    debug는 불리언입니다; 참이면, 디버깅 정보가 라이브러리에 포함됩니다 (대부분의 플랫폼에서, 이것이 중요한 곳은 컴파일 단계임에 유의하십시오: 단지 일관성을 위해 debug 플래그가 여기에 포함됩니다).

    target_lang은 주어진 오브젝트가 컴파일된 대상 언어입니다. 이를 통해 특정 언어의 특정 링크 시간 처리가 가능합니다.

    실패 시 `LibError`를 발생시킵니다.

  `link`(target_desc, objects, output_filename[, output_dir=None, libraries=None, library_dirs=None, runtime_library_dirs=None, export_symbols=None, debug=0, extra_preargs=None, extra_postargs=None, build_temp=None, target_lang=None])

    여러 가지를 함께 링크하여 실행 파일이나 공유 라이브러리 파일을 만듭니다.

    “여러 가지”는 objects로 제공되는 오브젝트 파일 리스트로 구성됩니다. output_filename은 파일명이어야 합니다. output_dir이 제공되면, output_filename은 이에 상대적입니다 (즉 output_filename은 필요하면 디렉터리 구성 요소를 제공할 수 있습니다).

    libraries는 링크할 라이브러리 리스트입니다. 이는 파일명이 아니라 라이브러리 이름입니다. 플랫폼에 특정한 방식으로 파일명으로 변환되기 때문입니다 (예를 들어 foo는 유닉스에서는 `libfoo.a`가 되고 DOS/윈도우에서는 `foo.lib`가 됩니다). 그러나, 이들은 디렉터리 구성 요소를 포함할 수 있습니다. 이는 링커가 모든 정상적인 위치를 검색하지 않고 특정 디렉터리를 찾는다는 의미입니다.

    제공되면, library_dirs는 맨 라이브러리 이름으로 지정된 라이브러리를 검색하기 위한 디렉터리 리스트이어야 합니다 (즉, 디렉터리 구성 요소가 없습니다). 이는 시스템 기본값과 `add_library_dir()` 및/또는 `set_library_dirs()`에 제공된 것 위에 있습니다. runtime_library_dirs는 공유 라이브러리에 내장되고, *그것*이 실행 시간에 의존하는 다른 공유 라이브러리를 검색하는 데 사용되는 디렉터리 리스트입니다. (이것은 유닉스에서만 의미 있을 수 있습니다.)

    export_symbols는 공유 라이브러리가 내보낼 심볼 리스트입니다. (이것은 윈도우에서만 의미 있는 것으로 보입니다.)

    debug는 `compile()`과 `create_static_lib()`와 같지만, 대부분의 플랫폼에서 실제로 중요하다는 약간의 차이가 있습니다 (대부분 형식을 위해 debug 플래그를 포함하는 `create_static_lib()`와 대조적입니다).

    extra_preargs와 extra_postargs는 `compile()`와 같습니다 (물론 사용 중인 특정 링커에 대한 명령 줄 인자를 제공한다는 점은 제외합니다).

    target_lang은 주어진 오브젝트가 컴파일된 대상 언어입니다. 이를 통해 특정 언어의 특정 링크 시간 처리가 가능합니다.

    실패 시 `LinkError`를 발생시킵니다.

  `link_executable`(objects, output_progname[, output_dir=None, libraries=None, library_dirs=None, runtime_library_dirs=None, debug=0, extra_preargs=None, extra_postargs=None, target_lang=None])

    실행 파일을 링크합니다. output_progname은 실행 파일의 이름이고, objects는 링크할 오브젝트 파일명 리스트입니다. 다른 인자는 `link()` 메서드와 같습니다.

  `link_shared_lib`(objects, output_libname[, output_dir=None, libraries=None, library_dirs=None, runtime_library_dirs=None, export_symbols=None, debug=0, extra_preargs=None, extra_postargs=None, build_temp=None, target_lang=None])

    공유 라이브러리를 링크합니다. output_libname은 출력 라이브러리의 이름이고, objects는 링크할 오브젝트 파일명 리스트입니다. 다른 인자는 `link()` 메서드와 같습니다.

  `link_shared_object`(objects, output_filename[, output_dir=None, libraries=None, library_dirs=None, runtime_library_dirs=None, export_symbols=None, debug=0, extra_preargs=None, extra_postargs=None, build_temp=None, target_lang=None])

    공유 오브젝트를 링크합니다. output_filename은 생성될 공유 오브젝트의 이름이고, objects는 링크할 오브젝트 파일명 리스트입니다. 다른 인자는 `link()` 메서드와 같습니다.

  `preprocess`(source[, output_file=None, macros=None, include_dirs=None, extra_preargs=None, extra_postargs=None])

    source로 명명된 단일 C/C++ 소스 파일을 전처리합니다. 출력은 output_file이나, 또는 output_file이 제공되지 않으면 stdout으로 기록됩니다. macros는 `compile()`에서와 같은 매크로 정의 리스트로, `define_macro()`와 `undefine_macro()`로 설정된 매크로 집합을 확장합니다. include_dirs는 `add_include_dir()`과 같은 방식으로 기본 리스트에 추가될 디렉터리 이름 리스트입니다.

    실패 시 `PreprocessError`를 발생시킵니다.

  다음 유틸리티 메서드는 다양한 구상 서브 클래스에서 사용하기 위해 `CCompiler` 클래스에 의해 정의됩니다.

  `executable_filename`(basename[, strip_dir=0, output_dir=''])

    주어진 basename에 대한 실행 파일의 파일명을 반환합니다. 일반적으로 윈도우가 아닌 플랫폼의 경우 basename과 같지만, 윈도우에서는 `.exe`가 추가됩니다.

  `library_filename`(libname[, lib_type='static', strip_dir=0, output_dir=''])

    현재 플랫폼에서 주어진 라이브러리 이름에 대한 파일명을 반환합니다. 유닉스에서 lib_type이 `'static'`인 라이브러리는 일반적으로 `liblibname.a` 형식이고, lib_type이 `'dynamic'` 인 라이브러리는 `liblibname.so` 형식입니다.

  `object_filenames`(source_filenames[, strip_dir=0, output_dir=''])

    주어진 소스 파일에 대한 오브젝트 파일의 이름을 반환합니다. source_filenames는 파일명 리스트이어야 합니다.

  `shared_object_filename`(basename[, strip_dir=0, output_dir=''])

    주어진 파일 이름 basename에 대한 공유 오브젝트 파일의 이름을 반환합니다.

  `execute`(func, args[, msg=None, level=1])

    `distutils.util.execute()`를 호출합니다. 이 메서드는 dry_run 플래그를 로깅하고 고려한 후, 주어진 인자 args로 파이썬 함수 func를 호출합니다.

  `spawn`(cmd)

    `distutils.util.spawn()`을 호출합니다. 이것은 주어진 명령을 실행하기 위해 외부 프로세스를 호출합니다.

  `mkpath`(name[, mode=511])

    `distutils.dir_util.mkpath()`를 호출합니다. 그러면 디렉터리와 누락된 조상 디렉터리를 만듭니다.

  `move_file`(src, dst)

    `distutils.file_util.move_file()`을 호출합니다. src를 dst로 이름을 바꿉니다.

  `announce`(msg[, level=1])

    `distutils.log.debug()`를 사용하여 메시지를 작성합니다.

  `warn`(msg)

    표준 에러에 경고 메시지 msg를 씁니다.

  `debug_print`(msg)

    이 `CCompiler` 인스턴스에 debug 플래그가 설정되어 있으면, msg를 표준 출력으로 인쇄하고, 그렇지 않으면 아무 작업도 수행하지 않습니다.

## 9.3. `distutils.unixccompiler` — 유닉스 C 컴파일러

이 모듈은 일반적인 유닉스 스타일 명령 줄 C 컴파일러를 다루는 `CCompiler`의 서브 클래스인 `UnixCCompiler` 클래스를 제공합니다:

- `-Dname[=value]`로 정의된 매크로

- `-Uname`으로 정의 해제된 매크로

- `-Idir`로 지정된 인클루드 검색 디렉터리

- `-llib`로 지정된 라이브러리

- `-Ldir`로 지정된 라이브러리 검색 디렉터리

- `-c` 옵션을 사용하여 cc (또는 이와 유사한) 실행 파일로 처리되는 컴파일: `.c`를 `.o`로 컴파일합니다.

- ar 명령으로 처리되는 정적 라이브러리 링크 (ranlib 사용 가능)

- cc `-shared`로 처리되는 공유 라이브러리 링크

## 9.4. `distutils.msvccompiler` — Microsoft 컴파일러

이 모듈은 Microsoft Visual Studio 용 추상 `CCompiler` 클래스의 구현인, `MSVCCompiler`를 제공합니다. 일반적으로, 확장 모듈은 파이썬을 컴파일하는 데 사용된 것과 같은 컴파일러로 컴파일해야 합니다. 파이썬 2.3과 이전 버전의 경우, 컴파일러는 Visual Studio 6이었습니다. 파이썬 2.4와 2.5의 경우, 컴파일러는 Visual Studio .NET 2003입니다.

`MSVCCompiler`는 일반적으로 자체적으로 올바른 컴파일러, 링커 등을 선택합니다. 이 선택을 재정의하려면, 환경 변수 DISTUTILS_USE_SDK와 MSSdk를 모두 설정해야 합니다. MSSdk는 현재 환경이 SDK의 `SetEnv.Cmd` 스크립트에 의해 설정되었거나, SDK가 설치될 때 환경 변수가 등록되었음을 나타냅니다. DISTUTILS_USE_SDK는 distutils 사용자가 `MSVCCompiler`의 컴파일러 선택을 재정의하도록 명시적으로 선택했음을 나타냅니다.

## 9.5. `distutils.bcppcompiler` — Borland 컴파일러

이 모듈은 Borland C++ 컴파일러용 추상 `CCompiler` 클래스의 서브 클래스인 `BorlandCCompiler`를 제공합니다.

## 9.6. `distutils.cygwincompiler` — Cygwin 컴파일러

이 모듈은 윈도우로의 GNU C 컴파일러의 Cygwin 이식을 다루는 `UnixCCompiler`의 서브 클래스인 `CygwinCCompiler` 클래스를 제공합니다. 또한 GCC의 mingw32 이식을 다루는 Mingw32CCompiler 클래스도 포함합니다 (no-cygwin 모드의 cygwin과 같습니다).

## 9.7. `distutils.archive_util` — 아카이브 유틸리티

이 모듈은 tar나 zip 파일과 같은 아카이브 파일을 만들기 위한 몇 가지 함수를 제공합니다.

`distutils.archive_util.``make_archive`(base_name, format[, root_dir=None, base_dir=None, verbose=0, dry_run=0])

  아카이브 파일(예를 들어 `zip`이나 `tar`)을 만듭니다. base_name은 만들 파일의 이름에서 형식별 확장자를 뺀 것입니다; format은 아카이브 형식입니다: `zip`, `tar`, `gztar`, `bztar`, `xztar` 또는 `ztar` 중 하나입니다. root_dir은 아카이브의 루트 디렉터리가 될 디렉터리입니다; 즉, 일반적으로 아카이브를 만들기 전에 root_dir로 `chdir` 합니다. base_dir은 아카이빙을 시작하는 디렉터리입니다; 즉. base_dir은 아카이브에 있는 모든 파일과 디렉터리의 공통 접두사입니다. root_dir과 base_dir 모두 기본값은 현재 디렉터리입니다. 아카이브 파일의 이름을 반환합니다.

  버전 3.5에서 변경: `xztar` 형식에 대한 지원이 추가되었습니다.

`distutils.archive_util.``make_tarball`(base_name, base_dir[, compress='gzip', verbose=0, dry_run=0])

  ‘base_dir과 그 밑의 모든 파일로 구성된 tar 파일로 (선택적으로 압축된) 아카이브를 만듭니다. compress는 `'gzip'` (기본값), `'bzip2'`, `'xz'`, `'compress'` 또는 `None`이어야 합니다. `'compress'` 방법의 경우 compress라는 이름의 압축 유틸리티가 기본 프로그램 검색 경로에 있어야 하므로, 이는 유닉스에 한정된 것일 수 있습니다. 출력 tar 파일의 이름은 `base_dir.tar`이며, 적절한 압축 확장자 (`.gz`, `.bz2`, `.xz` 또는 `.Z`)가 추가될 수 있습니다. 출력 파일명을 반환합니다.

  버전 3.5에서 변경: `xz` 압축에 대한 지원이 추가되었습니다.

`distutils.archive_util.``make_zipfile`(base_name, base_dir[, verbose=0, dry_run=0])

  base_dir과 그 밑의 모든 파일로 zip 파일을 만듭니다. 출력 zip 파일의 이름은 base_name + `.zip`입니다. (사용할 수 있으면) `zipfile` 파이썬 모듈이나 (설치되어 기본 검색 경로에 있으면) InfoZIP `zip` 유틸리티를 사용합니다. 두 도구를 모두 사용할 수 없으면, `DistutilsExecError`를 발생시킵니다. 출력 zip 파일의 이름을 반환합니다.

## 9.8. `distutils.dep_util` — 종속성 검사

이 모듈은 파일과 파일 그룹의 간단한 타임 스탬프 기반 종속성을 수행하는 함수를 제공합니다; 또한, 이러한 타임 스탬프 종속성 분석에 전적으로 기반하는 함수를 제공합니다.

`distutils.dep_util.``newer`(source, target)

  source가 존재하고 target보다 최근에 수정되었거나, source가 존재하고 target이 존재하지 않으면 참을 반환합니다. 둘 다 존재하고 target이 같은 연령이거나 source보다 새로우면 거짓을 반환합니다. source가 없으면 `DistutilsFileError`를 발생시킵니다.

`distutils.dep_util.``newer_pairwise`(sources, targets)

  두 개의 파일명 리스트를 병렬로 탐색하여, 각 소스가 해당 대상보다 최신인지 테스트합니다. `newer()`의 의미에 따라 소스가 대상보다 최신인 리스트 쌍 (sources, targets)를 반환합니다.

`distutils.dep_util.``newer_group`(sources, target[, missing='error'])

  sources에 나열된 파일과 관련하여 target이 오래되었으면 참을 반환합니다. 즉, target이 존재하고 sources의 모든 파일보다 최신이면 거짓을 반환합니다; 그렇지 않으면 참을 반환합니다. missing은 소스 파일이 누락되었을 때 수행하는 작업을 제어합니다; 기본값(`'error'`)은 `os.stat()` 내부에서 오는 `OSError`로 터뜨리는 것입니다; `'ignore'`이면, 누락된 소스 파일을 조용히 무시합니다; `'newer'`이면, 누락된 소스 파일은 target이 최신이 아니라고 가정하도록 합니다 (“dry_run” 모드에서 편리합니다: 입력이 누락되어 작동하지 않는 명령을 수행하는 척합니다만, 실제로 명령을 실행하지 않기 때문에 중요하지 않습니다.)

## 9.9. `distutils.dir_util` — 디렉터리 트리 연산

이 모듈은 디렉터리와 디렉터리 트리에서 작동하는 함수를 제공합니다.

`distutils.dir_util.``mkpath`(name[, mode=0o777, verbose=0, dry_run=0])

  디렉터리와 누락된 모든 조상 디렉터리를 만듭니다. 디렉터리가 이미 존재하면 (또는 name이 현재 디렉터리를 의미하는 빈 문자열이면, 물론 당연히 존재합니다), 아무 작업도 수행하지 않습니다. 도중에 일부 디렉터리를 만들 수 없으면 `DistutilsFileError`를 발생시킵니다 (예를 들어 일부 하위 경로가 있지만, 디렉터리가 아니라 파일이면). verbose가 참이면, 각 mkdir의 한 줄 요약을 stdout에 인쇄합니다. 실제로 만들어진 디렉터리 리스트를 반환합니다.

`distutils.dir_util.``create_tree`(base_dir, files[, mode=0o777, verbose=0, dry_run=0])

  base_dir 아래에 files를 넣는 데 필요한 모든 빈 디렉터리를 만듭니다. base_dir은 아직 존재할 필요는 없는 디렉터리의 이름일 뿐입니다; files는 base_dir에 상대적으로 해석할 파일명 리스트입니다. base_dir + files에 있는 모든 파일의 디렉터리 부분이 아직 존재하지 않는다면 만들어집니다. mode, verbose 및 dry_run 플래그는 `mkpath()`와 같습니다.

`distutils.dir_util.``copy_tree`(src, dst[, preserve_mode=1, preserve_times=1, preserve_symlinks=0, update=0, verbose=0, dry_run=0])

  전체 디렉터리 트리 src를 새 위치 dst로 복사합니다. src와 dst는 모두 디렉터리 이름이어야 합니다. src가 디렉터리가 아니면, `DistutilsFileError`를 발생시킵니다. dst가 없으면, `mkpath()`로 만들어집니다. 복사의 최종 결과는 src의 모든 파일이 dst로 복사되고, src 아래의 디렉터리가 재귀적으로 dst로 복사된다는 것입니다. 출력 이름을 사용하여, 복사되었거나 복사되었어야 할 파일 리스트를 반환합니다. 반환 값은 update나 dry_run의 영향을 받지 않습니다: 단순히 src 아래의 모든 파일 리스트이며, 이름이 dst 아래로 변경된 것입니다.

  preserve_mode와 preserve_times는 `distutils.file_util.copy_file()`과 같습니다; 디렉터리가 아닌 일반 파일에만 적용됨에 유의하십시오. preserve_symlinks가 참이면, 심볼릭 링크가 심볼릭 링크로 복사됩니다 (지원하는 플랫폼에서!); 그렇지 않으면 (기본값), 심볼릭 링크의 대상이 복사됩니다. update와 verbose는 `copy_file()`과 같습니다.

  `.nfs`로 시작하는 src의 파일은 건너뜁니다 (이러한 파일에 대한 자세한 내용은 NFS FAQ page의 답변 D2에서 볼 수 있습니다).

  버전 3.3.1에서 변경: NFS 파일은 무시됩니다.

`distutils.dir_util.``remove_tree`(directory[, verbose=0, dry_run=0])

  directory와 그 아래의 모든 파일과 디렉터리를 재귀적으로 제거합니다. 모든 에러는 무시됩니다 (verbose가 참이면 `sys.stdout`에 보고되는 것은 제외하고).

## 9.10. `distutils.file_util` — 단일 파일 연산

이 모듈에는 개별 파일에서 작동하는 몇 가지 유틸리티 함수가 포함되어 있습니다.

`distutils.file_util.``copy_file`(src, dst[, preserve_mode=1, preserve_times=1, update=0, link=None, verbose=0, dry_run=0])

  src 파일을 dst로 복사합니다. dst가 디렉터리이면, src는 같은 이름으로 거기에 복사됩니다; 그렇지 않으면, 파일명이어야 합니다. (파일이 존재하면, 무자비하게 파괴될 것입니다.) preserve_mode가 참(기본값)이면, 파일의 모드(유형과 권한 비트, 또는 현재 플랫폼에서 유사한 무엇이건)가 복사됩니다. preserve_times가 참(기본값)이면, 마지막 수정과 마지막 액세스 시간도 복사됩니다. update가 참이면, dst가 존재하지 않거나, dst가 존재하지만 src보다 오래된 경우에만 src가 복사됩니다.

  link를 사용하면 복사하는 대신 하드 링크(`os.link()` 사용)나 심볼릭 링크(`os.symlink()` 사용)를 만들 수 있습니다: `'hard'`나 `'sym'`으로 설정하십시오; `None`(기본값)이면, 파일이 복사됩니다. 지원하지 않는 시스템에서는 link를 설정하지 마십시오: `copy_file()`은 하드나 심볼릭 링크를 사용할 수 있는지 확인하지 않습니다. `_copy_file_contents()`를 사용하여 파일 내용을 복사합니다.

  튜플 `(dest_name, copied)`를 반환합니다: dest_name은 출력 파일의 실제 이름이고, 파일이 복사되었으면 (또는 dry_run이 참이면, 복사했어야 할 것이면) copied는 참입니다.

`distutils.file_util.``move_file`(src, dst[, verbose, dry_run])

  src 파일을 dst로 이동합니다. dst가 디렉터리이면, 파일은 같은 이름으로 거기에 이동됩니다; 그렇지 않으면, src는 단지 dst로 이름이 바뀝니다. 파일의 새로운 전체 이름을 반환합니다.

  경고

  `copy_file()`을 사용하여 유닉스에서 장치 간 이동을 처리합니다. 다른 시스템은 어떻습니까?

`distutils.file_util.``write_file`(filename, contents)

  filename이라는 파일을 만들고 그곳에 contents(줄 종결자가 없는 문자열 시퀀스)를 씁니다.

## 9.11. `distutils.util` — 기타 유틸리티 함수

이 모듈에는 다른 유틸리티 모듈에 맞지 않는 잡동사니가 포함되어 있습니다.

`distutils.util.``get_platform`()

  현재 플랫폼을 식별하는 문자열을 반환합니다. 주로 플랫폼별 빌드 디렉터리와 플랫폼별 빌드 배포판을 구분하는 데 사용됩니다. 포함된 정확한 정보는 OS에 따라 다르지만, 일반적으로 OS 이름과 버전 및 아키텍처를 포함합니다 (‘os.uname()’에서 제공되는); 예를 들어, 리눅스에서는 커널 버전이 특별히 중요하지 않습니다.

  반환된 값의 예:

  - `linux-i586`

  - `linux-alpha`

  - `solaris-2.6-sun4u`

  POSIX가 아닌 플랫폼의 경우, 현재는 `sys.platform` 만 반환합니다.

  Mac OS X 시스템의 경우 OS 버전은 현재 시스템의 OS 버전이 아니라, 바이너리가 실행될 최소 버전(즉, 파이썬 빌드 중 `MACOSX_DEPLOYMENT_TARGET`의 값)을 반영합니다.

  Mac OS X의 유니버설 바이너리 빌드의 경우 아키텍처값은 현재 프로세서의 아키텍처 대신 유니버설 바이너리 상태를 반영합니다. 32비트 유니버설 바이너리의 경우 아키텍처는 `fat`, 64비트 유니버설 바이너리의 경우 아키텍처는 `fat64`, 4방향 유니버설 바이너리(4-way universal binaries)의 경우 아키텍처는 `universal`입니다. 파이썬 2.7과 파이썬 3.2부터 아키텍처 `fat3`은 3방향 유니버설 빌드 (ppc, i386, x86_64)에 사용되고 `intel`은 i386과 x86_64 아키텍처의 유니버설 빌드에 사용됩니다.

  Mac OS X에서 반환되는 값의 예:

  - `macosx-10.3-ppc`

  - `macosx-10.3-fat`

  - `macosx-10.5-universal`

  - `macosx-10.6-intel`

`distutils.util.``convert_path`(pathname)

  ‘pathname’을 네이티브 파일 시스템에서 작동할 이름으로 반환합니다, 즉 ‘/’로 분할하고 현재 디렉터리 구분자를 사용하여 다시 합칩니다. 설정 스크립트의 파일명은 항상 유닉스 스타일로 제공되고, 파일 시스템에서 실제로 사용하기 전에 로컬 규칙으로 변환해야 해서 필요합니다. pathname이 슬래시로 시작하거나 끝나면 유닉스가 아닌 시스템에서 `ValueError`를 발생시킵니다.

`distutils.util.``change_root`(new_root, pathname)

  new_root가 앞에 추가된 pathname을 반환합니다. pathname이 상대적이면, `os.path.join(new_root,pathname)`과 동등합니다. 그렇지 않으면, pathname을 상대적으로 만든 다음 두 개를 결합해야 하는데, 이는 DOS/윈도우에서는 까다롭습니다.

`distutils.util.``check_environ`()

  사용자가 구성 파일, 명령 줄 옵션 등에서 사용할 수 있도록 보장하는 모든 환경 변수가 ‘os.environ’에 있도록 합니다. 현재 여기에는 다음이 포함됩니다:

  - `HOME` - 사용자의 홈 디렉터리 (유닉스 전용)

  - `PLAT` - 하드웨어와 OS를 포함한, 현재 플랫폼에 대한 설명 (`get_platform()`을 참조하십시오)

`distutils.util.``subst_vars`(s, local_vars)

  s에서 셸/Perl 스타일 변수 치환을 수행합니다. `$` 다음에 이름이 오는 모든 항목은 변수로 간주하며, 변수는 local_vars 딕셔너리에 있는 값으로 치환되거나, local_vars에 없으면 `os.environ`에 있는 값으로 치환됩니다. os.environ은 특정 값들이 포함되어 있도록 보장하기 위해 먼저 확인/보강됩니다: `check_environ()`을 참조하십시오. local_vars나 `os.environ`에서 찾을 수 없는 변수에 대해 `ValueError`를 발생시킵니다.

  이것은 완전한 문자열 보간 함수가 아님에 유의하십시오. 유효한 `$variable`은 대문자와 소문자, 숫자와 밑줄로만 구성될 수 있습니다. { } 또는 ( ) 스타일 인용을 사용할 수 없습니다.

`distutils.util.``split_quoted`(s)

  따옴표와 역 슬래시에 대한 유닉스 셸과 유사한 규칙에 따라 문자열을 분할합니다. 간단히 말해서: 단어는 스페이스가 역 슬래시로 이스케이프 되거나 따옴표로 묶인 문자열 안에 있지 않은 한 스페이스로 구분됩니다. 작은따옴표와 큰따옴표는 동등하며, 따옴표 문자는 역 슬래시 이스케이프 될 수 있습니다. 역 슬래시는 두 문자 이스케이프 시퀀스에서 제거되어, 이스케이프 된 문자만 남깁니다. 따옴표 문자는 따옴표로 묶인 문자열에서 제거됩니다. 단어 리스트를 반환합니다.

`distutils.util.``execute`(func, args[, msg=None, verbose=0, dry_run=0])

  외부 세계에 영향을 미치는 어떤 작업을 수행합니다 (예를 들어, 파일 시스템에 쓰기). 이러한 작업은 dry_run 플래그에 의해 비활성화되기 때문에 특별합니다. 이 메서드는 당신을 위해 모든 관료적 절차를 관리합니다; 여러분은 호출할 함수와 이를 위한 인자 튜플(수행되는 “외부 작업”을 내재하기 위해) 및 인쇄할 선택적 메시지를 제공하기만 하면 됩니다.

`distutils.util.``strtobool`(val)

  논릿값의 문자열 표현을 true (1) 또는 false (0) 로 변환합니다.

  참값은 `y`, `yes`, `t`, `true`, `on` 및 `1`입니다; 거짓 값은 `n`, `no`, `f`, `false`, `off` 및 `0`입니다. val이 다른 값이면 `ValueError`를 발생시킵니다.

`distutils.util.``byte_compile`(py_files[, optimize=0, force=0, prefix=None, base_dir=None, verbose=1, dry_run=0, direct=None])

  파이썬 소스 파일 모음을 `__pycache__` 하위 디렉터리의 `.pyc` 파일로 바이트 컴파일합니다 (PEP 3147과 PEP 488을 참조하십시오). py_files는 컴파일할 파일 리스트입니다; `.py`로 끝나지 않는 모든 파일은 조용히 건너뜁니다. optimize는 다음 중 하나여야 합니다:

  - `0` - 최적화하지 않습니다

  - `1` - 일반 최적화 (`python -O`처럼)

  - `2` - 추가 최적화 (`python -OO`처럼)

  force가 참이면, 타임 스탬프와 관계없이 모든 파일이 다시 컴파일됩니다.

  각 바이트 코드 파일에 인코딩된 소스 파일명은 기본적으로 py_files에 나열된 파일명입니다; prefix와 basedir로 수정할 수 있습니다. prefix는 각 소스 파일명에서 제거되는 문자열이고, base_dir은 (prefix가 제거된 후) 앞에 추가되는 디렉터리 이름입니다. 원하는 대로, prefix와 base_dir 중 하나나 둘 다 제공 할 수 있습니다 (또는 아무것도 제공하지 않아도 됩니다).

  dry_run이 참이면, 파일 시스템에 영향을 미치는 작업을 실제로 수행하지 않습니다.

  바이트 컴파일은 표준 `py_compile` 모듈을 사용하여 이 인터프리터 프로세스에서 직접 수행되거나, 임시 스크립트를 작성하고 실행하여 간접적으로 수행됩니다. 일반적으로, `byte_compile()`이 직접 컴파일을 사용할지를 파악하도록 해야 합니다 (자세한 내용은 소스를 참조하십시오). direct 플래그는 간접 모드에서 생성된 스크립트에서 사용됩니다; 무엇을 하고 있는지 모른다면, `None`으로 그냥 두십시오.

  버전 3.2.3에서 변경: 현재 디렉터리에 태그가 없는 파일 대신 `__pycache__` 하위 디렉터리에, 이름에 `임포트 매직 태그`가 있는 `.pyc` 파일을 만듭니다.

  버전 3.5에서 변경: PEP 488에 따라 `.pyc` 파일을 만듭니다.

`distutils.util.``rfc822_escape`(header)

  각 줄 바꿈 뒤에 8개의 스페이스가 있도록 하여, RFC 822 헤더에 포함하기 위한 이스케이프 된 header 버전을 반환합니다. 문자열의 다른 수정은 하지 않음에 유의하십시오.

## 9.12. `distutils.dist` — Distribution 클래스

이 모듈은 빌드/설치/배포 중인 모듈 배포를 나타내는 `Distribution` 클래스를 제공합니다.

## 9.13. `distutils.extension` — Extension 클래스

이 모듈은 설정 스크립트에서 C/C++ 확장 모듈을 기술하는 데 사용되는 `Extension` 클래스를 제공합니다.

## 9.14. `distutils.debug` — Distutils 디버그 모드

이 모듈은 DEBUG 플래그를 제공합니다.

## 9.15. `distutils.errors` — Distutils 예외

Distutils 모듈에서 사용하는 예외를 제공합니다. Distutils 모듈은 표준 예외를 발생시킬 수 있음에 유의하십시오; 특히 명백히 최종 사용자의 잘못인 에러(예를 들어 잘못된 명령 줄 인자)에 대해 일반적으로 SystemExit가 발생합니다.

이 모듈은 `from ... import *` 모드에서 사용하기에 안전합니다; 이름이 `Distutils`로 시작하고 `Error`로 끝나는 심볼만 내보냅니다.

## 9.16. `distutils.fancy_getopt` — 표준 getopt 모듈을 감싸는 래퍼

이 모듈은 다음과 같은 추가 기능을 제공하는 표준 `getopt` 모듈에 대한 래퍼를 제공합니다:

- 짧고 긴 옵션이 함께 묶입니다

- 옵션에는 도움말 문자열이 있어서, `fancy_getopt()`는 잠재적으로 완전한 사용법 요약을 만들 수 있습니다

- 옵션은 전달된 객체의 어트리뷰트를 설정합니다

- 불리언 옵션은 “부의 별칭”을 가질 수 있습니다 — 예를 들어 `--quiet`가 `--verbose`의 “부의 별칭”이면, 명령 줄의 `--quiet`는 verbose를 거짓으로 설정합니다.

`distutils.fancy_getopt.``fancy_getopt`(options, negative_opt, object, args)

  래퍼 함수. options는 `FancyGetopt`의 생성자에 설명된 대로 `(long_option, short_option, help_string)` 3-튜플의 리스트입니다. negative_opt는 옵션 이름을 옵션 이름에 매핑하는 딕셔너리이어야 하며, 키와 값은 모두 options 리스트에 있어야 합니다. object는 값을 저장하는 데 사용되는 객체입니다 (`FancyGetopt` 클래스의 `getopt()` 메서드를 참조하십시오). args는 인자 리스트입니다. `None`을 args로 전달하면 `sys.argv[1:]`을 사용합니다.

`distutils.fancy_getopt.``wrap_text`(text, width)

  text를 width 너비 미만으로 래핑합니다.

class `distutils.fancy_getopt.``FancyGetopt`([option_table=None])

  option_table은 3-튜플 리스트입니다: `(long_option, short_option, help_string)`

  옵션이 인자를 취하면, long_option에 `'='`가 추가되어야 합니다; short_option은 단일 문자여야 하며, 어떤 경우에도 `':'`이 아니어야 합니다. long_option에 대응하는 short_option이 없으면 short_option은 `None`이어야 합니다. 모든 옵션 튜플에는 긴 옵션이 있어야 합니다.

`FancyGetopt` 클래스는 다음 메서드를 제공합니다:

`FancyGetopt.``getopt`([args=None, object=None])

  args에서 명령 줄 옵션을 구문 분석합니다. object에 어트리뷰트로 저장합니다.

  args가 `None`이거나 제공되지 않으면, `sys.argv[1:]`을 사용합니다. object가 `None`이거나 제공되지 않으면, 새 `OptionDummy` 인스턴스를 만들고, 여기에 옵션값을 저장하고, 튜플 `(args, object)`를 반환합니다. object가 제공되면, 제자리에서 수정되고 `getopt()`는 args 만 반환합니다; 두 경우 모두, 반환된 args는 전달된 args 리스트의 수정된 복사본이며, 전달된 args는 그대로 유지됩니다.

`FancyGetopt.``get_option_order`()

  `getopt()`의 이전 실행에서 처리한 `(option, value)` 튜플 리스트를 반환합니다. `getopt()`가 아직 호출되지 않았으면 `RuntimeError`를 발생시킵니다.

`FancyGetopt.``generate_help`([header=None])

  이 `FancyGetopt` 객체에 대한 옵션 테이블에서 도움말 텍스트(문자열 리스트, 제안된 출력 줄 당 하나씩)를 생성합니다.

  제공되면, 도움말 맨 위에 제공된 header를 인쇄합니다.

## 9.17. `distutils.filelist` — FileList 클래스

이 모듈은 `FileList` 클래스를 제공하며, 파일 시스템에 대한 정보를 확인하고 파일 리스트를 구축하는 데 사용됩니다.

## 9.18. `distutils.log` — 간단한 PEP 282 스타일 로깅

## 9.19. `distutils.spawn` — 서브 프로세스 스폰

이 모듈은 서브 프로세스에서 다른 프로그램을 시작하기 위한 다양한 플랫폼별 함수의 프런트엔드인 `spawn()` 함수를 제공합니다. 또한 주어진 실행 파일 이름을 경로에서 검색하는 `find_executable()`을 제공합니다.

## 9.20. `distutils.sysconfig` — 시스템 구성 정보

`distutils.sysconfig` 모듈은 파이썬의 저수준 구성 정보에 대한 액세스를 제공합니다. 사용 가능한 특정 구성 변수는 플랫폼과 구성에 따라 크게 달라집니다. 특정 변수는 실행 중인 파이썬의 특정 버전에 대한 빌드 프로세스에 따라 다릅니다; 변수는 유닉스 시스템에서 파이썬과 함께 설치되는 `Makefile`과 구성 헤더에 있는 변수입니다. 구성 헤더는 파이썬 버전 2.2부터 `pyconfig.h`이고, 이전 버전의 파이썬에서는 `config.h`입니다.

`distutils` 패키지의 다른 부분에 대해 유용한 조작을 수행하는 몇 가지 추가 함수가 제공됩니다.

`distutils.sysconfig.``PREFIX`

  `os.path.normpath(sys.prefix)`의 결과.

`distutils.sysconfig.``EXEC_PREFIX`

  `os.path.normpath(sys.exec_prefix)`의 결과.

`distutils.sysconfig.``get_config_var`(name)

  단일 변수의 값을 반환합니다. 이것은 `get_config_vars().get(name)`과 동등합니다.

`distutils.sysconfig.``get_config_vars`(...)

  변수 정의 집합을 반환합니다. 인자가 없으면, 구성 변수의 이름을 값에 매핑하는 딕셔너리를 반환합니다. 인자가 제공되면, 해당 인자는 문자열이어야 하며, 반환 값은 관련 값을 제공하는 시퀀스가 됩니다. 주어진 이름에 해당 값이 없으면, 해당 변수에 `None`이 포함됩니다.

`distutils.sysconfig.``get_config_h_filename`()

  구성 헤더의 전체 경로 이름을 반환합니다. 유닉스의 경우, 이것은 configure 스크립트에 의해 생성된 헤더입니다; 다른 플랫폼의 경우 헤더는 파이썬 소스 배포에서 직접 제공됩니다. 이 파일은 플랫폼별 텍스트 파일입니다.

`distutils.sysconfig.``get_makefile_filename`()

  파이썬을 빌드하는 데 사용된 `Makefile`의 전체 경로 이름을 반환합니다. 유닉스의 경우, 이것은 configure 스크립트에 의해 생성된 파일입니다; 다른 플랫폼의 경우 의미는 다양합니다. 존재한다면, 이 파일은 플랫폼별 텍스트 파일입니다. 이 함수는 POSIX 플랫폼에서만 유용합니다.

`distutils.sysconfig.``get_python_inc`([plat_specific[, prefix]])

  일반이나 플랫폼 종속 C 인클루드 파일에 대한 디렉터리를 반환합니다. plat_specific이 참이면, 플랫폼 종속 인클루드 디렉터리가 반환됩니다; 거짓이거나 생략되면, 플랫폼 독립적인 디렉터리가 반환됩니다. prefix가 주어지면, `PREFIX` 대신 prefix로 사용되거나, plat_specific이 참이면 `EXEC_PREFIX` 대신 exec-prefix로 사용됩니다.

`distutils.sysconfig.``get_python_lib`([plat_specific[, standard_lib[, prefix]]])

  일반이나 플랫폼 종속 라이브러리 설치를 위한 디렉터리를 반환합니다. plat_specific이 참이면, 플랫폼 종속 라이브러리 디렉터리가 반환됩니다; 거짓이거나 생략되면, 플랫폼 독립적인 디렉터리가 반환됩니다. prefix가 주어지면, `PREFIX` 대신 prefix로 사용되거나, plat_specific이 참이면 `EXEC_PREFIX` 대신 exec-prefix로 사용됩니다. standard_lib가 참이면, 제삼자 확장을 설치하기 위한 디렉터리가 아니라 표준 라이브러리의 디렉터리가 반환됩니다.

다음 함수는 `distutils` 패키지 내에서만 사용하려는 것입니다.

`distutils.sysconfig.``customize_compiler`(compiler)

  `distutils.ccompiler.CCompiler` 인스턴스의 모든 플랫폼별 사용자 정의를 수행합니다.

  이 함수는 현재 유닉스에서만 필요하지만, 미래 호환성을 지원하기 위해 일관되게 호출되어야 합니다. 유닉스 버전에 따라 다른 정보를 삽입하고 파이썬의 `Makefile`에 저장됩니다. 이 정보에는 선택한 컴파일러, 컴파일러와 링커 옵션, 링커에서 공유 객체에 사용하는 확장이 포함됩니다.

이 함수는 훨씬 더 특수한 용도이며, 파이썬 자체 빌드 절차에서만 사용해야 합니다.

`distutils.sysconfig.``set_python_build`()

  파이썬을 위한 빌드 프로세스의 일부로 사용되고 있음을 `distutils.sysconfig` 모듈에 알립니다. 이렇게 하면 파일의 상대적 위치가 많이 변경되어, 설치된 파이썬이 아닌 빌드 영역에 위치 할 수 있도록 합니다.

## 9.21. `distutils.text_file` — TextFile 클래스

이 모듈은 `TextFile` 클래스를 제공합니다. 이 클래스는 (선택적으로) 주석 제거, 빈 줄 무시 및 역 슬래시 된 줄의 결합을 처리하는 텍스트 파일에 대한 인터페이스를 제공합니다.

class `distutils.text_file.``TextFile`([filename=None, file=None, **options])

  이 클래스는 줄 단위 문법을 갖는 텍스트 파일을 처리할 때 일반적으로 수행하려는 모든 작업을 처리하는 파일류 객체를 제공합니다: 주석 제거 (`#`가 주석 문자라면), 빈 줄 무시, 줄 바꿈을 이스케이프 한 인접 줄을 연결하기 (즉, 줄 끝의 역 슬래시), 선행 및/또는 후행 공백 제거. 이들 모두는 선택적이고 독립적으로 제어할 수 있습니다.

  이 클래스는 `warn()` 메서드를 제공해서 문제의 논리적 줄이 여러 물리적 줄에 걸쳐있는 경우에도 물리적 줄 번호를 보고하는 경고 메시지를 생성할 수 있습니다. 또한 한 번에 한 줄씩 미리 보기를 구현하기 위한 `unreadline()`을 제공합니다.

  `TextFile` 인스턴스는 filename, file 또는 둘 모두로 만들어집니다. 둘 다 `None`이면 `RuntimeError`가 발생합니다. filename은 문자열이어야 하며, file은 파일 객체(또는 `readline()`과 `close()` 메서드를 제공하는 것)여야 합니다. `TextFile`이 경고 메시지에 포함할 수 있도록, 최소한 filename을 제공하는 것이 좋습니다. file이 제공되지 않으면, `TextFile`은 `open()` 내장 함수를 사용하여 스스로 만듭니다.

  옵션은 모두 불리언이며, `readline()`이 반환하는 값에 영향을 줍니다.

  옵션 이름 | 설명 | 기본값
  --- | --- | ---
  strip_comments | `'#'`에서 줄 끝까지 제거할 뿐만 아니라, `'#'` 앞까지 이어지는 모든 공백을 제거합니다 — 역 슬래시로 이스케이프 되지 않는 한 | 참
  lstrip_ws | 반환하기 전에 각 줄에서 선행 공백을 제거합니다 | 거짓
  rstrip_ws | 반환하기 전에 각 줄에서 후행 공백(줄 종결자 포함!)을 제거합니다. | 참
  skip_blanks | 주석과 공백을 제거한 *후에* 빈 줄을 건너뜁니다. (lstrip_ws와 rstrip_ws가 모두 거짓이면, 일부 행은 공백으로만 구성될 수 있습니다: 이것은 skip_blanks가 참인 경우에도 건너뛰지 *않습니다*.) | 참
  join_lines | 주석과 공백을 제거한 후 역 슬래시가 줄 넘김이 아닌 줄의 마지막 문자이면, 다음 줄을 결합하여 하나의 논리적 줄을 만듭니다; N개의 연속된 줄이 역 슬래시로 끝나면, N+1개의 물리적 줄이 결합하여 하나의 논리적 줄을 형성합니다. | 거짓
  collapse_join | 앞줄에 연결된 줄에서 선행 공백을 제거합니다; `(join_lines and not lstrip_ws)`일 때만 중요합니다 | 거짓

  rstrip_ws는 후행 줄 바꿈을 제거할 수 있어서, `readline()`의 의미는 내장 파일 객체의 `readline()` 메서드와 달라야 함에 유의하십시오! 특히, `readline()`은 파일 끝에 대해 `None`을 반환합니다: rstrip_ws가 참이지만 skip_blanks가 거짓이면, 빈 문자열은 단지 빈 줄(또는 모두 공백인 줄)일 수 있습니다.

  `open`(filename)

    새 파일 filename을 엽니다. 이것은 file이나 filename 생성자 인자를 재정의합니다.

  `close`()

    현재 파일을 닫고 (파일명과 현재 줄 번호를 포함하여) 그것에 대해 알고 있는 모든 것을 잊어버립니다.

  `warn`(msg[, line=None])

    현재 파일의 현재 논리적 줄에 연결된 경고 메시지를 (stderr로) 인쇄합니다. 파일의 현재 논리적 줄이 여러 물리적 줄에 걸쳐있으면, 경고는 전체 범위를 나타냅니다, 가령 `"lines 3-5"`. line이 제공되면, 현재 줄 번호를 대체합니다; 물리적 줄의 범위를 나타내는 리스트나 튜플이거나, 단일 물리적 줄을 나타내는 정수일 수 있습니다.

  `readline`()

    현재 파일에서 단일 논리적 줄을 읽고 반환합니다 (또는 줄이 이전에 `unreadline()`으로 “되돌린” 경우 내부 버퍼에서). join_lines 옵션이 참이면, 여러 물리적 줄을 단일 문자열로 이어붙인 줄을 읽는 것이 수반될 수 있습니다. 현재 줄 번호를 갱신해서, `readline()` 후에 `warn()`을 호출하면 방금 읽은 물리적 줄에 대한 경고가 표시됩니다. rstrip_ws가 참이지만 strip_blanks가 거짓이면 빈 문자열이 발생할 수 있어서, 파일 끝에서는 `None`을 반환합니다.

  `readlines`()

    현재 파일에 남아있는 모든 논리적 줄의 리스트를 읽고 반환합니다. 이렇게 하면 현재 줄 번호가 파일의 마지막 줄로 갱신됩니다.

  `unreadline`(line)

    line(문자열)을 향후 `readline()` 호출에서 확인할 내부 버퍼로 푸시합니다. 한 번에 한 줄씩 미리 보기가 있는 구문 분석기를 구현하는 데 편리합니다. `unreadline()`으로 “되돌린” 줄은 `readline()`으로 읽을 때 이후에 다시 정리(공백 제거 등)되지 않음에 유의하십시오. `readline()`을 호출하기 전에 `unreadline()`을 여러 번 호출하면, 가장 최근의 것이 첫 번째로 오는 순서로 줄이 반환됩니다.

## 9.22. `distutils.version` — 버전 번호 클래스

## 9.23. `distutils.cmd` — Distutils 명령을 위한 추상 베이스 클래스

이 모듈은 추상 베이스 클래스 `Command`를 제공합니다.

class `distutils.cmd.``Command`(dist)

  Distutils의 “일벌”인 명령 클래스를 정의하기 위한 추상 베이스 클래스. 명령 클래스에 대한 유용한 비유는 options라는 로컬 변수가 있는 서브 루틴으로 생각하는 것입니다. 옵션은 `initialize_options()`에서 선언되고 `finalize_options()`에서 정의됩니다 (최종값 제공). 두 메서드 모두 모든 명령 클래스에서 정의해야 합니다. 옵션값은 외부 세계(명령 줄, 구성 파일, …)에서 올 수 있고, 다른 옵션에 종속된 모든 옵션은 이러한 외부 영향이 처리된 후에 계산되어야 해서 — 그래서 `finalize_options()`, 둘 사이의 구분이 필요합니다. 옵션값을 기반으로 모든 작업을 수행하는 서브 루틴의 본문은 `run()` 메서드이며, 역시 모든 명령 클래스에서 구현해야 합니다.

  클래스 생성자는 `Distribution` 인스턴스인 단일 인자 dist를 취합니다.

## 9.24. 새 Distutils 명령 만들기

이 섹션에서는 새 Distutils 명령을 만드는 단계를 간략하게 설명합니다.

새로운 명령은 `distutils.command` 패키지의 모듈에 있습니다. 해당 디렉터리에 `command_template`라는 샘플 템플릿이 있습니다. 구현 중인 새 명령과 이름이 같은 새 모듈에 이 파일을 복사하십시오. 이 모듈은 모듈(및 명령)과 같은 이름의 클래스를 구현해야 합니다. 예를 들어, `peel_banana` 명령을 만들려면 (사용자가 `setup.py peel_banana`를 실행할 수 있도록), `command_template`를 `distutils/command/peel_banana.py`에 복사한 다음, `distutils.cmd.Command`의 서브 클래스인 `peel_banana` 클래스를 구현하도록 편집합니다.

`Command`의 서브 클래스는 다음 메서드를 정의해야 합니다.

`Command.``initialize_options`()

  이 명령이 지원하는 모든 옵션의 기본값을 설정합니다. 이러한 기본값은 다른 명령, 설정 스크립트, 구성 파일 또는 명령 줄에 의해 재정의될 수 있습니다. 따라서, 이것은 옵션 간의 종속성을 코딩하는 곳이 아닙니다; 일반적으로 `initialize_options()` 구현은 한 무더기의 `self.foo = None` 대입일 뿐입니다.

`Command.``finalize_options`()

  이 명령이 지원하는 모든 옵션에 대한 최종값을 설정합니다. 이것은 항상 가능한 한 늦게 호출됩니다, 즉, 명령 줄이나 다른 명령에서 모든 옵션 대입이 완료된 후에. 따라서, 이것이 옵션 종속성을 코딩하는 장소입니다: foo가 bar에 의존하면, foo가 `initialize_options()`에서 대입된 것과 같은 값을 여전히 가지고 있는 한 foo를 bar에서 설정하는 것이 안전합니다.

`Command.``run`()

  명령의 존재 이유: 수행하기 위해 존재하는 작업을 수행하고, `initialize_options()`에서 초기화되고, 다른 명령, 설정 스크립트, 명령 줄 및 구성 파일로 사용자 정의되고, `finalize_options()`에서 마무리된 옵션으로 제어됩니다. 모든 터미널 출력과 파일 시스템 상호 작용은 `run()`에서 수행해야 합니다.

`Command.``sub_commands`

  sub_commands는 명령의 “패밀리” 개념을 형식화합니다, 예를 들어, 하위 명령 `install_lib`, `install_headers` 등이 있는 부모로서의 `install`. 명령 패밀리의 부모는 sub_commands를 클래스 어트리뷰트로 정의합니다; 2-튜플 `(command_name, predicate)`의 리스트인데, command_name은 문자열이고 predicate는 함수, 문자열 또는 `None`입니다. predicate는 해당 명령이 현재 상황에서 적용 가능한지를 결정하는 상위 명령의 메서드입니다. (예를 들어 `install_headers`는 설치할 C 헤더 파일이 있을 때만 적용됩니다.) predicate가 `None`이면, 해당 명령은 항상 적용 가능합니다.

  sub_commands는 일반적으로 클래스의 끝에서 정의됩니다, predicate는 클래스의 메서드일 수 있는데, 이때는 이미 정의되어 있어야 하기 때문입니다. 규범적 예는 install 명령입니다.

## 9.25. `distutils.command` — 개별 Distutils 명령

## 9.26. `distutils.command.bdist` — 바이너리 설치 프로그램 빌드

## 9.27. `distutils.command.bdist_packager` — 패키저를 위한 추상 베이스 클래스

## 9.28. `distutils.command.bdist_dumb` — “dumb” 설치 프로그램 빌드

## 9.29. `distutils.command.bdist_msi` — Microsoft 설치 프로그램 바이너리 패키지 빌드

class `distutils.command.bdist_msi.``bdist_msi`

  Windows Installer (.msi) 바이너리 패키지를 빌드합니다.

  대부분의 경우, `bdist_msi` 설치 프로그램은 Win64 플랫폼에 대한 더 나은 지원을 제공하고, 관리자가 비대화 형 설치를 수행할 수 있도록 하며, 그룹 정책을 통한 설치를 허용하기 때문에 `bdist_wininst` 설치 프로그램보다 더 나은 선택입니다.

## 9.30. `distutils.command.bdist_rpm` — Redhat RPM과 SRPM으로 바이너리 배포판 구축

## 9.31. `distutils.command.bdist_wininst` — 윈도우 설치 프로그램 빌드

버전 3.8부터 폐지: 대신 bdist_wheel(휠 패키지)을 사용하십시오.

## 9.32. `distutils.command.sdist` — 소스 배포판 빌드

## 9.33. `distutils.command.build` — 패키지의 모든 파일 빌드

## 9.34. `distutils.command.build_clib` — 패키지의 모든 C 라이브러리 빌드

## 9.35. `distutils.command.build_ext` — 패키지의 모든 확장 빌드

## 9.36. `distutils.command.build_py` — 패키지의 .py/.pyc 파일 빌드

class `distutils.command.build_py.``build_py`

class `distutils.command.build_py.``build_py_2to3`

  설치할 각 .py 파일에 대해 2to3 변환 라이브러리를 실행하는 build_py의 대체 구현입니다. 파이썬 2.x와 3.x 모두에서 실행되도록 설계된 배포판의 setup.py 파일에서 이를 사용하려면, 여러분의 setup.py 에 다음을 추가하십시오:

      try:
          from distutils.command.build_py import build_py_2to3 as build_py
      except ImportError:
          from distutils.command.build_py import build_py

  그리고 나중에:

      cmdclass = {'build_py': build_py}

  를 setup() 호출에 추가하십시오.

## 9.37. `distutils.command.build_scripts` — 패키지의 스크립트 빌드

## 9.38. `distutils.command.clean` — 패키지 빌드 영역 정리

이 명령은 중간 컴파일된 오브젝트 파일과 같이 build와 하위 명령에 의해 만들어진 임시 파일들을 제거합니다. `--all` 옵션을 사용하면, 전체 빌드 디렉터리가 제거됩니다.

제자리에서 빌드된 확장 모듈은 빌드 디렉터리에 없기 때문에 정리되지 않습니다.

## 9.39. `distutils.command.config` — 패키지 구성 수행

## 9.40. `distutils.command.install` — 패키지 설치

## 9.41. `distutils.command.install_data` — 패키지에서 데이터 파일 설치

## 9.42. `distutils.command.install_headers` — 패키지에서 C/C++ 헤더 파일 설치

## 9.43. `distutils.command.install_lib` — 패키지에서 라이브러리 파일 설치

## 9.44. `distutils.command.install_scripts` — 패키지에서 스크립트 파일 설치

## 9.45. `distutils.command.register` — 파이썬 패키지 색인에 모듈 등록

`register` 명령은 패키지를 파이썬 패키지 색인에 등록합니다. 이것은 PEP 301에 더 자세히 설명되어 있습니다.

## 9.46. `distutils.command.check` — 패키지의 메타 데이터 확인

`check` 명령은 패키지의 메타 데이터에 대해 몇 가지 테스트를 수행합니다. 예를 들어, 모든 필수 메타 데이터가 `setup()` 함수에 전달된 인자로 제공되는지 확인합니다.