<비공식 번역>awesome-c Beginner 번역: 11. Resource linking

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'의 공식적인 번역이 아니며 검수를 받은 것 역시 아닙니다!!

---

11 : Resource linking ( 11 : 리소스 연결 )

우리는 지금 대부분의 빌드 시스템이 작업하는 단계를 지났습니다. 유감스럽게도, 리소스 링킹은 설치와 동시에 수행되어야하는 것입니다; 일반적인 해결방법(많은 사람들이 이것이 해결방법인지 깨닫지 못한 많은 프로젝트에서 이 방법은 반복적으로 적용됐습니다.)은 수동으로 해당 단계를 수행하도록 빌드 규칙을 작성하는 것입니다. 윈도우에서, 상황이 나은편입니다. 왜냐하면 Visual Studio는 링킹 이후에 리소스 링크를 수행하기 때문입니다(따라서 이것은 설치가 수행되기 직전에 동작합니다.).

"리소스 링크"라는 개념은 윈도우에서부터 왔습니다만, 일반적인 원칙은 여러 운영체제에도 동일합니다: 평범한 실행파일 그 자체로는 특별히 사용할 수 없습니다. 왜냐면 모든 것은 파일이름을 가지고 (여러분이 운이 좋다면) 문서도 가질 것이기 때문입니다. 문서는 사람에게는 유용할 수도 있지만, nethack4.exe 같은 이름으로 컴퓨터가 무언가를 할 수 있지만 스크롤을 통해서는 수천의 실행파일 목록을 위치해도 누구도 스크롤하지 않을 것입니다. (역자주: 정말 의미가 이해 안 가는 문장입니다. 원문 : Documentation might be useful to a human, but what can a computer do with a name like nethack4.exe but place it in a list of thousands of other executables that nobody will ever scroll through?) (이건 단지 가설이 아닙니다; 이것은 파일을 열  프로그램을 선택하기 위해 리눅스에 있는 파이어폭스의 실제 UI입니다, 여러분이 이미 적절한 옵션을 알지 못하는 경우,  수동으로 /usr/bin에 이동하여 "파일 열기" 다이얼로그 박스를 열어야하기 때문입니다. 이건 여러분이 원하는 모든 텍스트 파일을 에디터에서 열때마다 열받는 일입니다.)

분명히, 필요한 것은 일종의 메타데이터입니다 : 파일이름보다 긴 설명, 아이콘, 아마도 버전 번호, 그외에 그러한 것들.  윈도우에서는 실행파일로 컴파일 됩니다. 리눅스에서는 이는 잘 알려진 디렉토리 경로(/usr/share/applications)의 .desktop파일로 존재합니다; 많은 데스크탑 환경은 특정 실행파일들이 요구하는 메타데이터를 잡아내기 위해서 이러한 파일들의 인덱스를 유지합니다. (누군가는 관심을 가질지는 모르지만, 저는 Mac OS X에서도 동일한지는 확신할 수 없습니다.)

빌드 시스템이 알려지지 않은 모든 메타데이터를 아는 것은 불가능합니다. 그러나, aimake는 OS에 따라서 적당한 포멧으로 확실히 바꿀 수 있고 적당한 shot을 만드는데에 필요한 정보의 양은 실제로 매우 적습니다. (적어도 합리적인 추측과 그럴듯한 위치에 있을 수 있는 버전 번호나 아이콘같은 정보의 한 조각; 만약 그것이 특정되어 있지 않다면, OS에게 디폴트로 존재하는 아이콘을 사용하라고 전달합니다.)

설치 이후에 수행하는 것보다는 이전 단계에 이를 수행하는 것은 매우 합리적일 것입니다, Visual Studio는 이처럼 하지 않습니다, 저는 원래처럼 리소소를 그 장소(/usr/share/applications)에 넣을려고 했었습니다. 그러나 설치한 후에 이를 수행하는 것은 (aimake가 여전히 권한이 상승되어 있는 동안, 시스템 디렉토리 /usr/share/applications에 리소스를 write 할 수 있습니다.) aimake 코드 상에서는 훨씬 간단하다는 걸 밝혀냈습니다(별도로 실행파일의 pre-resource-link와 post-resource-link 버전을 처리하지 않음으로 NetHack 4의 aimake.rules를 만드는 것은 간단했습니다). 게다가 윈도우에서 여러분이 시작 메뉴 바로가기를 만들고 싶다면, 윈도우즈 셸 링크는 overengineering 과 underengineering의 기묘한 조합이기 때문에 (그 중 일부는 다른 곳에서 좋지 못한 설계를 일으킵니다.), 목표대상이 그 시점에 존재하지 않는다면 견고하게 동작하는 바로가기를 만드는 것은 불가능합니다. (이러한 이유 때문에 aimake는 설치과정에서 현재 이러한 숏컷을 만들지 않습니다. 또한 존재하는 wrapper들의 대다수가 잘못된 API들을 사용하기 때문에, 제가 새로운 wrapper를 작성할 때는, aimake와 통신하는 코드를 작성하기 전에는 c++코드가 153줄이었습니다.)

재미있는 사실은, 두 가지 NetHack 4 실행파일, nethack4 와 nethack4-sdl은 단지 파일이름과 메타데이터의 차이뿐 이라는 겁니다 (리눅스에서 nethack4-sdl은 심볼릭 링크입니다, 메타데이터가 외부 파일에 있기 때문입니다). 서로다른 파일이름은 사용할() 기본 인터페이스 플러그인을 결정할 뿐만 아니라 인터페이스의 차이를 설명합니다, 메타데이터는 nethack4에 대한 터미널 창을 요청하는데 사용됩니다, nethack4-sdl을 오픈하지 않는동안 이 일은 필요하지 않고 이는 이상해보일 것이기 때문입니다.

(역자 주: 이 부분은 위에서 설명한 리소스 링킹에 대해서 Nethack4가 어떻게 동작하는지에 대해 설명한 부분인 것 같습니다. 눈여겨 볼 필요는 없어보입니다.)

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

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