프로젝트 규모가 조금 커지면 간혹 만나볼 수 있는 문제다.
주로 프로젝트 관리가 체계적이지 못하거나 잘못되어 발생하는 문제인데, 의외로 원인을 찾는데 시간이 조금 걸린다.
문제의 원인이 여럿이기 때문이지만, 크게 중요한 문제가 아니라서 생각되어 그냥 넘어가기도 한다.
하지만 개인적으로는 이 문제를 매 수행 시 개발자를 번거롭게 할 뿐 아니라 빌드의 정합성을 보장하지 못 하게 하는 문제로 판단한다.
지금까지 경험했던 원인은 다음과 같았는데,
1. 빌드 대상인 파일이 모종의 원인에 의하여 마지막 수정 시간이 현재 시간보다 꽤나 앞으로 설정된 경우
이 경우 obj 파일에 찍힌 timestamp 보다 cpp 파일의 수정 시간이 항상 크기 때문에 항상 빌드를 요청한다.
대개 시간과 얽힌 테스트를 할 때 시스템(OS) 시간을 조정하면서 작업을 하다보면 저도 모르게 발생함.
2. 실제 include 되어 사용하지만 프로젝트에는 포함되지 않은 파일이 있는 경우
대개 헤더파일의 경우가 많이 발생하는데 (유니티 빌드의 경우는 cpp도 발생함) 결국 timestamp 비교가
온전치 못해 발생한다.
또는 프로젝트에는 필터에 포함되어 있으나 실제 파일이 없는 경우도 동일하게 발생한다.
3. lib 파일의 timestamp 가 꼬여서 현재 시간보다 먼 미래로 가버렸을 때
꼬임의 이유야 몇 개 있겠지만 본질적으로 1번과 크게 다르지 않고 소스와는 달리 알아채기 어렵지 않다.
소스는 파일이 매우 많아서 찾기 어려울 수 있지만 lib 파일은 출력폴더의 특정 확장자만 뒤져보면 되기 때문
기억나지는 않지만 아마 몇 가지 사소한 원인이 더 있었다고 기억하는데, 오늘 새로운 원인을 접했다.
이것도 본질적으로는 그냥 프로젝트 관리 실수에다 timestamp 와 연관이 있는 문제여서 다른 원인들과 같은 범주다.
4. 프로젝트들의 PCH 파일명이 동일하여 뒷 프로젝트가 앞 프로젝트 PCH 를 덮어쓴 경우
이 원인을 찾기 위해 헤맸던 이유가, out of date 가 나는 양상이 기존 것들과 약간 차이가 있었기 때문인데,
clean and rebuild(build) => 성공
바로 리빌드 시 => 빌드 실패 (가장 이해하기 힘들었던 부분)
+ 빌드 => 리링킹(?)
+ 빌드 => 변경된 파일이 없으므로 빌드는 하지 않고 최후 lib 파일만 작성(timestamp 갱신)
+ 빌드 => 빌드 성공 (이후로는 빌드하지 않음)
웃기는 건 저 다섯 단계 사이에서 어느 시점에 실행하느냐에 따라 계속 out of date 가 나기도 하고
한 번만 더 빌드하기도 하고 한다는 점이다.
이런 랜덤한 양상을 겪고 나니 그 동안 희석되었던 PCH 에 대한 거부감이 다시 살짝 살아날 뻔했지만...
빌드 환경을 정리해주는 것으로 해결하였다.
