makefile에“설치”대상이 필요한 이유는 무엇입니까?

18

C 및 C ++의 세계에서 온 대부분의 빌드 시스템에는 installMakefile ( 예 : GNU 에서 권장하는 위치 ) 또는 CMake 등의 대상이 있습니다. 이 대상은 운영 체제 (예 : C:\Program Files\Windows) 의 런타임 파일 (실행 파일, 라이브러리 등)을 복사합니다 .

나에게있어서 프로그램을 설치하는 것은 빌드 시스템의 책임이 아니기 때문에 (실제로 운영 체제 / 패키지 관리자의 책임 임) 이것은 해킹처럼 느껴집니다 . 또한 빌드 시스템 또는 빌드 스크립트가 환경 변수, 레지스트리 변수, 심볼릭 링크, 권한 등 으로 설치된 프로그램의 구성을 알아야 함을 의미합니다 .

기껏해야 빌드 시스템 release에는 설치 가능한 프로그램 (예 : .deb또는 .msi) 을 출력 할 대상이 있어야 하며 운영 체제에 해당 프로그램을 설치하도록 요청하십시오. 또한 사용자가 입력하지 않고도 제거 할 수 make uninstall있습니다.

그래서 내 질문 : 왜 빌드 시스템이 일반적으로 install목표를 갖는 것이 좋습니다 ?

— 신 시스
소스

7

"설치 설치"는 빌드 시스템의 책임에 속하지 않지만 설치 가능한 패키지를 작성하는 데 훨씬 더 관여하고 플랫폼 고유의 책임이 있습니다.

— pmf

2

어쨌든 : 때로는 패키지 관리자 등을 사용하여 해결할 수없는 충돌을 일으키는 종속성이 있기 때문에 OS / 패키지 관리자가 처리 하지 않는 응용 프로그램을 설치하려고합니다 . make install일반적으로 설치에 따라 /usr/local(또는 /opt)은 "핵심 OS / 패키지 관리 시스템"에 의해 처리되지 디렉토리에있는. 그래도 Windows에 비슷한 규칙이 있는지는 알 수 없습니다.

— Bakuriu

11

"이것은 정말 해키 느낌입니다." C / C ++의 세계에서 무엇을 기대 했습니까? ;-)

— Mason Wheeler

1

주 make install우리는 크로스 컴파일에 대해 이야기 할 때 이해되지 않는다

— 하겐 폰 Eitzen

1

@HagenvonEitzen와 함께 DESTDIR합니다.

— Nax 'vi-vim-nvim'11

23

많은 빌드 스크립트 또는 Makefile은 패키지 관리자가 존재하기 전에 만들어 졌기 때문에 설치 대상이 있으며 오늘날 많은 시스템에도 패키지 관리자가 없기 때문에 설치 대상이 있습니다. 또한, 시스템이 있습니다 make install사실 입니다 패키지를 관리하는 좋은 방법은.

— 요 르그 W 미타 그
소스

make install선호되는 시스템이 궁금 합니다. 그 외에도 makefile이 설치 가능한 패키지를 만들어야한다고 말했을 때 프로그램 관리자를 의미했습니다 . 거의 모든 OS에 설치된 프로그램을 관리하는 방법이 있다고 생각합니까? 예를 들어, Windows에는 저장소를 제외하고 패키지 관리자가 없지만 설치된 프로그램을 관리 할 수있는 방법이 있습니다 ( .msi예를 들어 패키지를 통해 )

— Synxis

2

@Synxis BSD, Linux, Unix는 모두 makefile을 사용합니다. 설치에 사용하는 것이 바람직한 지 여부는 모르겠지만 종종을 사용하는 기능이 make install있습니다.

— Rob

1

데비안에서 적어도 사용하는 것이 바람직 것 checkinstall이상의 make install두 가지 이유 ". 당신은 쉽게 한 단계로 패키지를 제거 할 수 있습니다" "여러 컴퓨터에 결과 패키지를 설치할 수 있습니다." -checkinstall이 .deb를 빌드하고 설치할 때 패키지 관리자를 사용합니다.

— Aaron Hall

1

@Synxis-패키지 관리자가 tar 파일을 다운로드하여 프로그램을 설치 한 후 압축을 풀고 실행하는 리눅스 배포본 (소스 배포판이라고 함)이 여러 개 있습니다.make install

— slebetman

1

@AaronHall 내가 틀렸다면 나를 수정하지만, checkinstall실제로 호출이 패키지 빌드에 대한 작업을 사용 make install 하고 모니터링 한다는 인상을 받았습니다 .

— cmaster-monica reinstate

5

A makefile에는 install대상 이 없을 수 있으며 , 더 중요한 것은 설치 가능하지 않은 프로그램을 가질 수 있습니다 (예 : 빌드 디렉토리에서 실행해야하거나 어디서나 설치할 수 있기 때문에). install대상 단지입니다 컨벤션 평소에 makefile-s.

그러나 많은 프로그램에서 외부 리소스 (예 : 글꼴, 데이터베이스, 구성 파일 등)를 실행해야합니다. 그리고 그들의 실행 파일은 종종 이러한 리소스에 대한 가설을 만듭니다. 예를 들어, bash쉘은 일반적으로 /etc/bash.bashrc등에서 초기화 파일을 읽습니다 . 이러한 자원은 일반적으로 파일 시스템 에 있으며 (파일 계층 구조에 대한 규칙 은 hier (7) 참조 ) 기본 파일 경로는 실행 파일에 빌드됩니다.

시스템의 대부분의 실행 파일에서 문자열 (1) 을 사용 하십시오. 알려진 파일 경로를 확인할 수 있습니다.

BTW,를 사용하는 많은 GNU 프로그램의 경우 루트없이 autoconf실행할 수 있습니다 make install DESTDIR=/tmp/destdir/. 그런 다음 /tmp/destdir/나중에 패키지화해야하는 파일로 채워집니다.

FWIW, 나는 bismon-chariot-doc.pdf 보고서에 설명 된 나의 bismon (GPLv3 + 라이센스) 프로그램을 "설치"할 수 없다고 믿는 경향이 있다. 나는 그것을 증명할 수 있는지 확실하지 않으며, 어떻게 그 프로그램을 설치 가능하게 만들 수 있는지 상상할 수 없다.

— 바 실레 스타 인케 비치
소스

2

DESTDIR 또는 다른 접두사를 너무 자주 잊어 버렸습니다. 동적 라이브러리와 같은 외부 리소스가 관련되는 즉시 소프트웨어를 설치할 위치를 모른 채 소프트웨어 를 구축 할 수 없습니다 . 비표준 위치 (예 : 또는) 에 설치하는 데에도 좋습니다 . 다른 접두사를 피하는 유일한 방법은 컨테이너를 사용하는 것이지만 물론 Linux 전용 솔루션입니다. /opt$HOME

— amon

2

DESTDIR이 경로 생성에 사용 되었기 때문에 DESTDIR = / tmp / destdir을 정상적인 위치에 설치할 때 나중에 작동하지 않는 패키지가 두 개 이상 있습니다.

— Joshua

@ amon : 컨테이너를 Linux 전용으로 특성화 할 것인지 잘 모르겠습니다. Linux는 컨테이너화의 일반적인 대상 플랫폼 일 수 있지만 대부분의 최신 운영 체제 에는 일부 형태의 컨테이너 기술 이 있습니다.

— 케빈

1

@Joshua DESTDIR은 설치 단계에서만 관련이 없어야합니다. 다음을 수행 할 수 있어야하며 문제없이 ./configure --prefix="/opt/foo" && make && DESTDIR=/tmp/foo make install 패키지를 재배치 할 수 있어야합니다 /opt/foo.

— Nax 'vi-vim-nvim'11

3

몇 가지 이유가 있습니다.

많은 패키지 작성 소프트웨어 ( 예 : 데비안 빌드 시스템, IIRC rpm)도 이미 빌드 스크립트에서 프로그램을 특정 하위 디렉토리에 "설치"할 것으로 예상합니다. 따라서 양방향 호환성에 의해 구동됩니다.
사용자는 $HOME디렉토리 와 같이 로컬 공간에 소프트웨어를 설치할 수 있습니다 . 모든 패키지 관리자가이를 지원하지는 않습니다.
여전히 패키지가없는 환경이있을 수 있습니다.

— 최대 630
소스

나는 그 질문에 대해 약간의 말을했다. 나는 makefile이 설치 가능한 패키지를 만들어야한다고 말했을 때 프로그램 관리자를 의미했다 .

— Synxis

1

언급되지 않은 한 가지 이유는 현재 버전의 소프트웨어를 사용하지 않거나 수정 된 버전의 소프트웨어를 사용하는 경우가 많습니다. 사용자 정의 패키지를 작성하는 것은 더 많은 작업 일뿐만 아니라 현재 작성되고 분배 된 패키지와 충돌 할 수 있습니다. 오픈 소스 코드에서 이것은 특히 사용중인 이후 버전에서 주요 변경 사항이 도입 된 경우에 많이 발생합니다.

현재 버전 2.0.1에있는 오픈 소스 프로젝트 FOO를 사용하고 있고 버전 1.3.0을 사용하고 있다고 가정합니다. 버전 2.0.0이 현재 수행중인 작업과 호환되지 않기 때문에 위의 어떤 것도 사용하고 싶지 않지만 2.0.1에는 단일 버그 수정이 필요합니다. make install옵션이 있으면 패키지 작성에 대한 걱정없이 수정 된 1.3.0 소프트웨어를 설치하여 시스템에 설치할 수 있습니다.

— 돔
소스

1

Linux 배포판은 일반적으로 프로그램 유지 관리와 패키지 유지 관리를 분리합니다. 패키지 생성을 통합하는 빌드 시스템은 프로그램 관리자가 패키지 유지 관리를 수행하도록 강요합니다.

이것은 일반적으로 나쁜 생각입니다. 배포판에는 내부 일관성을 확인하고, 여러 대상 플랫폼에 바이너리를 제공하고, 작은 변경을 수행하여 나머지 시스템과 더 잘 통합하고, 버그를보고하는 사용자에게 일관된 경험을 제공 할 수있는 많은 인프라가 있습니다.

빌드 시스템에서 직접 패키지를 생성하려면이 인프라를 모두 통합하거나 우회해야합니다. 통합하면 의문의 이익을 얻는 데 많은 작업이 필요하고이를 우회하면 사용자 경험이 악화됩니다.

이는 다자 시스템에서 일반적으로 나타나는 "식품 체인의 최상위"문제 중 하나입니다. 복잡한 시스템이 여러 개인 경우 다른 시스템을 조정하는 시스템의 명확한 계층 구조가 필요합니다.

소프트웨어 설치 관리의 경우 패키지 관리자는이 구성 요소이며 패키지의 빌드 시스템을 실행 한 다음 편리한 인터페이스 ( "설치 단계 후 디렉토리의 파일")를 통해 출력을 가져 와서 패키지를 생성하고 준비합니다. 리포지토리에 업로드합니다.

패키지 관리자는 빌드 시스템과 리포지토리 사이의 중간에 있으며 둘 다 잘 통합 할 수있는 최상의 위치에 있습니다.

당신이 자바 스크립트의 몇 가지를 통해 사용할 패키지 것을 눈치 챘을 수도 npm를 통해도 가능 apt이 자바 스크립트 사람들이 결정 주로 때문입니다 - npm및 관련 저장소가 불가능에 가까운 그것을 만든 그들의 먹이 사슬의 맨 될 줄 이 패키지들을 데비안 패키지로 보내십시오.

내 데비안 개발자 모자를 켠 상태 : 오픈 소스 소프트웨어를 배포 할 경우 배포 관리자에게 포장을 남겨 두십시오. 그것은 당신과 우리 모두의 많은 작업을 저장합니다.

— 사이먼 리히터
소스

당신은 왜 설치 대상이 있는지에 대해 아무 말도하지 않았으며, 당신이 작성한 대부분의 내용이 그것에도 적용되는 것 같습니다.

— curiousdannii

1

@curiousdannii,있을 필요가 일부 빌드 시스템 및 패키지 관리자 사이의 인터페이스, 그리고 원, 그래서 이것은 단순한 하나가 발생합니다.

— Simon Richter

1

응용 프로그램 개발자는 각 파일의 위치를 알아야합니다. 그들은 문서에 그것을 남겨두고 패키지 관리자가 그것을 읽고 각 패키지에 대한 스크립트를 작성하도록 할 수 있습니다. 패키지 관리자가 설명서를 잘못 해석하여 작동 할 때까지 스크립트를 디버깅해야 할 수도 있습니다. 이것은 비효율적입니다. 응용 프로그램 개발자는 자신이 작성한 응용 프로그램을 올바르게 설치하기위한 스크립트를 작성하는 것이 좋습니다.

그는 임의의 이름으로 설치 스크립트를 작성하거나 다른 스크립트의 절차의 일부로 만들 수 있습니다. 그러나 표준 설치 명령 make install(패키지 관리자보다 먼저 사용되는 규칙)이 있으면 패키지를 만드는 것이 정말 쉬워졌습니다. Archlinux 패키지를 만들기위한 PKGBUILD 템플릿을 보면 , 실제로 패키지하는 기능이 단순히 수행하는 것을 볼 수 있습니다 make DESTDIR="$pkgdir/" install. 이것은 아마도 대부분의 패키지에서 작동하고 약간 수정하면 더 효과적입니다. make표준 (및 오토 툴) 덕분에 패키징은 정말 쉽고 쉽습니다.

— 졸
소스