<비공식 번역>awesome-c Beginner 번역: 10. Installation

현재위치

1. Configuration

2. Standard directory dectection

3. Source file dependency calculation

4. Header file location

5. Header precompileation

6. Preprocessing

7. Compliation and assembly

8. Object file dependency calculation

9. Linking

10. Installation

11. Resource linking

12. Package generation

13. Dynamic linking

<주의!!>

nethack4.org의 'Building C Projects'의 공식적인 번역이 아니며 검수를 받은 것 역시 아닙니다!!

---

10 : Installation (10 : 설치)

여러분은 실행파일이 생성되면 빌드는 완료되었다고 생각할 수 있지만, 여전히 전체 빌드 프로세스에는 몇 단계가 남아 있습니다. 이 시점의 빌드 프로세스에서 한가지 문제는 비록 우리가 동작하는 실행파일을 가지고 있지만, 이를 출시(역자주 : 릴리즈로 이해하시면 됩니다.)하는 것은 매우 어렵습니다. 실행파일, 오브젝트 파일, 소스 파일이 함께 혼합될 소스 트리에서 한가지 가능한 빌드 레이아웃은 (동일한 소스에서 멀티 빌드가 불가능하기 때문에 제가 개인적으로 싫어하는 어떤 것 그리고 그것은 빌드를 어렵게 하지만 그럼에도 매우 일반적인),너무나도 무질서하게 제공되기 쉽습니다. 빌드하는 동안 분리된 디렉토리에서 파일을 생성하는 것입니다. 그것은 실행파일이 필요로 하는 데이터로부터 분리되어 있음을 의미합니다 (여전히 소스 트리에 있는 동안). 어느 쪽이든, 몇몇 파일은 그들이 사용되기 전에 복사 및 재구성 되야합니다.

설치의 가능한한 가장 간단한 형태는 사용자가 설치를 요청한 위치에 복사하고, 그곳에서 연관된 데이터 파일과 함께 우리가 빌드한 파일을 사용하는 것입니다(다시 구성하는 동안, 빌드의 시작점에서). 이것에 대해서 개념적으로 어려운 부분은 없습니다. 그러나 상승된 권한을 요구하는 가능성 때문에 실제 구축에서는 거의 항상 별개의 과정입니다(일반 유저가 쓸 수 없는 시스템 디렉토리, 리눅스로 치면 /usr/bin, 윈도우에서는 CSIDL_PROGRAM_FILES의 서브디렉토리(파일시스템의 C:\Program Files)에 설치하기를 원하는 경우가 일반적입니다).

또한 빌드 시스템은 이 과정을 세밀하고 자세히 다룹니다. 예를 들어, 빌드 시스템은 설치하기 이전에 디렉토리를 만들 필요가 있습니다. 또다른 예는 그것들을 설치하는 동안 "strip" 실행파일의 공통부분 입니다; 이는 실행파일에서 동작하는데 절대적으로 필요하지 않은 모든 정보를 삭제합니다. 그래서 디버그의 비용으로 사용되는 디스크 사용량을 줄입니다. (최근 새로운 방법(혁신)은 디버그 정보를 일반적으로는 네트워크 상에 저장하고 디버깅 정보가 필요할 때 다운로드하여 별도의 파일에 분리하는 것입니다.)

설치 과정의 또다른 작업은 설치 파일에게 권한을 설정하는 것입니다. 이는 의외로 잘못되기 쉬운데, 특히 디폴트(기본)로부터 다른 것이 필요할 때 입니다. 예를 들면 리눅스나 UNIX 기반 시스템에서 일반적인 NetHack 그리고 특이한 NetHack 4 권한 설정에서 유저들은 nethack을 실행하거나 관리자 권한을 사용하지 않고서는 high score 테이블 또는 기본파일을 수정할 수 없습니다. 일부 배포판(설치 과정의 단계가 수정된, 설명서에 임의적인 새로운 구성은 좋지 못한 생각임을 명시했음에도)은 로컬 엑세스를 할 수 있는 모든 유저가 전체 시스템을 장악하는 보안적 버그를 소개하는 정도에 그쳐 망쳐진 관리가 됩니다.

또한 나중에 다룰 내용과 연관된 "DESTDIR 변환"에 주목할 가치가 있습니다. 이 아이디어는 여러분이 한 장소에 설치하는 것처럼 컴파일 합니다(예를 들면, 프로그램의 데이터 파일을 찾으려면 /usr/share), 그리고 실제 다른 위치에 컴파일된 파일을 배치하는 것이죠(일반적으로 여러분의 홈디렉토리 어딘가). 설치파일에 이 기능을 추가하는 것은 쉽습니다 그리고 망각은 완료가 거의 불가능한 빌드 프로세스의 이후 단계의 일부를 만들 것입니다. (여러분이 사용하는 GNU automake, 대부분 수기로 작성한 makefile들을 지정하는 방법은 make 변수에 DESTDIR;를 설정합니다. aimake는 커맨드 옵션 --destdir을 사용합니다.) 게다가 패키지 생성에서 이 방법은 사용되며, chroot를 설치할 때도 편리합니다; 저는 이 기능을 nethack4.org에서 서버 업데이트할 때 사용합니다.

아직까지, 이는 단순한 단계의 하나입니다. 빌드 시스템 디자이너의 관점에서 주요한 문제는 강화된 권한을 필요로하기 때문입니다, UI는 필연적으로 다른 단계에 비해 더 복잡할 것입니다. aimake는 설치단계를 다루기 위한 3가지 다른 모델을 지원합니다:

1. 만약 여러분이 실제 설치에서 권한을 필요하지 않는다면, 여러분은 -i  옵션을 사용할 수 있습니다. (즉, "빌드 뿐만이 아니라 설치까지도") 그리고 바로 여러분의 작업은 잘 됩니다.

2. 여러분이 만약 aimake에게 -s 옵션을 사용하여 권한을 상승할 수 있습니다. 예를 들면 -s sudo 그리고 이것은 그 메소드를 사용할 것입니다.(리눅스에서는 sudo, 윈도우즈에서는 UAC입니다; 오직 관리자 계정에서만 가능하며 비밀번호를 확인합니다. 또한 현재 보고있는 프로세스 하나만 권한상승이 일어납니다.)

3. 여러분은 빌드할 때 -i 옵션없이도 실행할 수 있습니다; 권한을 상승시키려면 -i --install-only 옵션으로 실행합니다. (이것은 내부적으로는 -s로 구현되어 있습니다.)

두 번째 방법은 가장 편안한 방법이고 권한 관련에러의 위험도를 최소화합니다 (여러분이 소유하지 않은 파일의 빌드 디렉토리 전체를 다루는 것). 세번째 방법은 다른 빌드 시스템 하나를 사용하는 것입니다. GNU autotool과 같은 aimake를 만든 wrapper를 작성하기 쉬운 것을 포함합니다.

출처1 : https://github.com/aleksandar-todorovic/awesome-c

출처2 : http://nethack4.org/blog/building-c.html