<비공식 번역>awesome-c Beginner 번역 : 3. Source file dependency calculation

현재위치

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

---

3: Source file dependency calculation(소스파일 종속 계산)

큰 프로젝트를 진행할 때, 여러분은 어떤 파일이 바뀔때마다 재컴파일하는 것을 피하고 싶어합니다. 오히려 실제로 변경된 조각부분만 컴파일하길 원합니다. 이 사실은 아마도 초기 빌드 프로세스 자동화 도구의 모티브일지도 모릅니다; 이런 종류의 최적화는 쉘스크립트나 batch파일에서 구현하기가 힘듭니다. 이는 make같은 도구의 창조로 이어지고 특정 빌드에서 수행해야 할 무언가를 결정하기 위해 타임스탬프를 비교합니다.

 

제가 요즘 주장하는 것은 make에 입력을 생성하기 위해 노력하는 것은 아마도 빌드 시스템에서  No.1으로 꼽을만한 가장 큰 실수 라는 것입니다. 비록 그것이 일반적인 관행일지라도 말입니다; 종속성 해결문제는 빌드에서 상대적으로 작은 부분이고, 다른 make에서 구현의 차이점은(그 중 일부는 매우 원시적입니다.) 매우 복잡하다는 것입니다. 따라서 일반적으로는 단지 그 작업을 수행할 make를 얻기위해 노력하는 것보다 종속성을 해결하는 것이 간단합니다. make는 또한 make는 할 수 있는일이 매우 제한되어 있습니다. 예를 들면 Makefile 변화에 해당 파일은 위한 빌드 규칙에서 파일 재구축에 대한 명백한 지원이 없습니다.(대조적으로 프로젝트의 전부 혹은 전무를 재건합니다.) 대부분의 빌드 시스템은 make의 포장으로서 작합니다. (또는 Visaul Strudio같은 IDE와 동일합니다.); aimake는 추상화의 단계를 건너뛰고 종속성 자체를 다룹니다. (이러한 결론에 도달한 첫번째 사람은 아닙니다. 예를 들어 Perl을 위한 표준 툴체인은 Makefile을 만드는 ExtUtils::MakeMaker를 사용했었습니다. 그러나 이제는 종속성 자체를 수행하는 Module::Build의 방향으로 이동하고 있습니다.

어쨋든 여러분이 make, aimake 또는 종속성 계산을 수행하는 완벽한 다른 도구를 사용하든 관계없이 여러분은 종속성이 실제로 무엇인지 알 필요가 있습니다. 원래 이것은 지정한 코드를 작성하는 사람에게 남겨진 것입니다. 그리고 여전히 간단한 프로젝트에 있습니다. 그러나 업무는 합리적으로 자동화 될 수 있습니다.(그리고 대형 프로젝트에서 이를 다루는 것은 다소 시간이 소요되는 일입니다.), 자동화는 이에 대해 많은 이해를 만듭니다.

어떤 많은 사람들은 종속성 계산에 대해 깨닫지 못하고있고 정확한 종속성 정보는 실제로 두가지 목적을 위해 필요합니다.

1. 만약 파일의 종속성이 바뀐다면 이것이 재구축 되는것을 보장한다.

2. 파일의 종속성이 있을때까지는 구축되지 않는것을 보장한다.

오늘날 종속성 자동화하는 대중적인 방법은 빌드하는 동안 포함되는 모든 헤더파일을 보고하는 전처리기를 얻는 것입니다. (그리고 전처리기는 고급지원이 꽤 있습니다.;  대부분은 직접 Makefile 조각을 생성할 수 있습니다.) 그러나 이것은 닭이 먼저냐 달걀이 먼저냐의 문제를 야기합니다.(여러분은 컴파일 하기전까지는 종속성을 계산할 수 없습니다. 그러나 종속성을 알기전까진 컴파일할 수 없습니다.) 이 문제에 대한 표준해결책은 (GNU 자동도구가 사용하는) 첫번째 빌드를 종속성 없이 시작하는 것입니다. 이 방법은 목적을 1을 만족합니다. (첫번째 빌드 때문에 모든 것은 어떤 재구성됩니다. 따라서 여러분은 종속성을 알지 못하는 것은 문제가 되지 않습니다.) 그러나 목적 2는 만족하지 못하는데 이 부분을 좋지 못한 방법을 사용하여 처리하는 경향이 있습니다. (이러한 혼란이 있습니다.)

다른 절충안은(그 중 하나는 aimake를 사용하는 것이죠, 다른 선택이은 여러분의 목표가 무엇인지에 따라 합리적인 부분이 있겠지만) 소스 파일을 분리된 공간에서 컴파일 없이 종속성을 얻어내기위해 전처리기를 통해 실행합니다. 따라서 aimake의 경우 빌드의 3단계에 해당됩니다. (반면에 다수의 다른 빌드시스템에선 이것은 6단계에 해당합니다.)

비록 이것이 컴파일의 부작용으로 나타나는 종속성 생산보다 간단해 보입니다. 현대의 전처리기는 실제로 여러분이 생각하는 것보다 훨씬 어려운일을 합니다. 첫 번째 문제는 타의적 헤더파일을 포함하는 것입니다; 이것은 빌드하길 원하는 것입니다. (여러분이 실제로 빌드하는 중이기 때문에), 그러나 종속성 계산은 당신이 원하는 것은 아닙니다. ("2차보다 선형"의 의미에서 실제로 컴파일없이 필요한 헤더를 보는 것이 훨씬 빠릅니다.) 다음 문제는 문제의 헤더가 아직 존재하지 않을 수도 있다는 것입니다. (예를 들어 그것들이 파일을 생성한다거나..) 그리고 (순서대로 aimake는 수행합니다.) 아직 위치하지 않았을 수도 있습니다. 적어도 gcc 와 clang은 이 문제를 해결하기 위해서 존재하지 않는 파일을 무시하라고 할 수 있습니다.

종속성 자동화를 구현하려는 제 첫 시도는 첫 번째 문제를 무시했습니다.(성능에 영향을 끼치는 것으로요) 그리고 두 번째 시도로 명백한 솔루션을 사용하지만 이는 합리적으로 미묘한 문제때문에 NetHack에서 예기치 않은 컴파일 실패가 나타납니다. NetHack의 파일 중 하나인 magic.h에 어떠한 일이 일어났습니다. 아직 소스트리의 부분으로 자리잡고 있지 않지만 (그리고 보통, 좋은 빌드 시스템은 사전 경고없이 컴파일하는 동안 임의의 파일을 생성하기 때문에, 헤더파일의 위치는 요점이 아닙니다. 즉, 생성 된 파일에 도움이 되지 않기 때문이죠.) 이것은 magic.h가 어디에 있던 괜찮습니다. gcc와 clang은 그것을 비었다고 취급하고 우리가 정정확히 원하는 종속성을 보고하기 때문입니다. 그러나 몇몇 OS는 시스템 헤더 magic.h를 가집니다.(저는 이것이 파일 포맷에 관련된 것이라 믿습니다.) 전처리기는 소스 트리보다는 시스템 헤더 magic.h의(그리고 모든 타행적 종속성도) 종속성을 보고합니다!

분명히, 제가 실제로 필요했던 행동은 실제로 헤더들을 포함하기보다는 비어있는 모든 헤더파일을 다루는 것입니다. 하지만 안타깝게도 일반적인 전처리기는 이러한 기능을 수행할 옵션을 포함하지 않습니다. 저는 실제로 제 문제를 해결하기 위해서 저만의 전처리기를 만들지를 심각하게 고민했습니다. 그러나 그것은 너무 엉망이었고 아마도 크기도 컸을 것입니다. (aimake는 configure처럼 여러분의 프로젝트와 함께 제공할 수 있도록 단일 파일로 구현되었습니다. 그래서 가능한한 사이즈를 유지하려면; 이미 1만 라인을 넘어섭니다.) 저는 결국 상황이 조금은 나쁠지라도 간단한 해결책을 찾아냈습니다 : aimake는 #include 구문을 보고서 헤더파일 자체를 읽고 찾아낸 각 헤더파일의 이름을 따서 빈 파일을 만듭니다. 그리고 전처리기에게 포함할 파일을 알립니다.

주의하세요. 종속성 처리의 방법의 제한점은 파일이 다른 파일의 헤더에 포함 된 상수에 기초하여 동적으로 포함되는 헤더파일을 결정할 수 없는 것입니다. 이 작업을 수행하는 그럴듯한 이유가 있습니다. 그리고 이것은 C 표준에 허용됩니다. 그러나 NetHact 4에서 실제로 일어나는 것을 살펴보면 거의 모든 위치에서 헤더 파일 포함이 원인인 실수로 밝혀졌습니다. (그리고 다른 경우는 합리적으로 정착합니다.) 이는 합리적인 절충을 만들기위한 것으로 보입니다.

번역자:

3번 문단을 번역하는데에 많은 시간이 걸렸습니다. 제 자체의 침체도 있었지만 아는 지식의 한계인지 번역에 많은 어려움을 겪었습니다.

번역기의 도움을 구했음에도 문장구조를 파악하기가 어려웠습니다.

추가적으로 수정을 거치도록 하겠습니다.

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

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