당신은 일반적으로 ./configure D 제품을 구축하기 위해 다음 명령을 호출 :"make install"은 규칙에 따라 설치 대상을 업데이트합니까?
make
make install
가 좋아,이 제품은 현재 시스템에있다. 그런 다음 일부 소스 코드 파일을 변경하고 make install 만 호출합니다. 문제는 기존의 install 타겟 구현에서 실행 파일을 다시 컴파일해야하는지 아니면 오래된 시스템 경로 만 적절한 시스템 경로에 복사해야합니까?
누구의 평범한 사람에 따라 다릅니다. 여기에 GNU convention입니다 :
는 실제 사용을 위해서 위치해야 할 파일 이름 등
프로그램을 컴파일하고 실행 파일들과 라이브러리를 복사 설치합니다.
그리고 이것은 합리적인 규칙처럼 보입니다. make install을 설치하면 오래된 실행 파일을 설치하는 것이 대부분 혼란을 일으킬 수 있습니다.
make은 종속성이 올바르게 설정된 경우 설계를 통해이를 처리합니다.
make은 helloworld이라는 이진 파일을 빌드하십시오. install 타겟을 쓸 것이므로이 helloworld 바이너리를 소스 디렉토리에서 /usr/bin으로 복사하십시오.
이것은 설치 대상이 helloworld 바이너리에 의존해야한다는 것을 의미합니다. 즉 바이너리 helloworld이 최신이 아닌 경우 다시 컴파일됩니다. make install을 입력하면 암시 적으로 make (기본 대상은 여기)이 호출됩니다.
eee .. 당신의 질문은 실제로 설치 대상이 무엇에 의존해야하는지에 대한 것입니다. – Ben
예, 잘 작성된 makefile은 install이 설치된 실행 파일 (또는 all)에 종속되므로 설치하기 전에 실행 파일이 최신인지 확인합니다.
분할에 대한 몇 가지 이유가 있습니다. 일반적으로 기본 대상은 all이며 파일을 설치하지 않고 빌드 만합니다. 개발자에게는 시스템의 나머지 부분에 영향을주지 않으면 서 쉽게 작업 환경에서 소스를 빌드 할 수 있습니다. 최종 사용자의 경우 빌드를 일반 사용자로 실행 한 다음 make install 만 루트로 실행해야합니다.
기술적으로는 make 단계 인 make; make install이 중복됨을 의미합니다.
그리고 이것은 * 아주 나쁜 것입니다 *. 'make install'을 루트로 실행할 때, 빌드 프로그램은 종종/dev/null 삭제와 같은 예기치 않은 일들을 할 수 있습니다. –
내 인생에서 그렇게 보지 못했습니다. @ 젠 : 그래서'make install'을 루트 권한으로 실행하지 않는 것이 좋습니다. 얼마나 잘 작동할지 모르겠다. –
아니, 제 추천은 자동으로 빌드하지 않는 make install 스크립트를 작성하는 것입니다. –