CLR 컴파일 옵션은 크게 /clr, /clr:pure, /clr:safe로 나뉜다. 이 중에서 가장 쓸모 있는 건 역시 /clr이다. 옵션 간의 차이점에 대해선 MSDN을 참고하도록 하고, /clr 컴파일을 자동화할 때의 이슈를 알아보자.
C++/CLI 프로젝트를 /clr 컴파일할 때 선택할만한 전략은 크게 세 가지이다.
-
프로젝트 전체에 /clr 옵션을 주고, 모든 cpp 파일을 /clr 컴파일한다. 이것은 비주얼 스튜디오에서 CLR 프로젝트를 생성할 때 쓰는 기본값이다. 순수한 CLR 어셈블리를 만들 때 쓸만한 전략이지만, 네이티브 C++ 기능만 쓰는 코드 파일까지 /clr 컴파일을 하게 된다. 추가적인 성능 상의 하락은 필연적이다. 추천할 수 없는 방법이다.
-
Expert C++/CLI란 책에서 추천하는 방법은 이렇다. 프로젝트 전체 설정에선 /clr을 뺀다. CLR 기능을 쓰는 코드 파일만 따로 옵션을 준다.
-
두 번째 방법과 정반대로 할 수도 있다. 프로젝트 전체 설정에 /clr 옵션을 주고, 네이티브 코드 파일에만 /clr 옵션을 주는 것이다. 물론 이 방법은 기존 네이티브 프로젝트를 CLR 프로젝트로 확장할 땐 상당히 귀찮을 수 있다.
세 가지 전략 중 가장 아름다운(?) 것은 역시 두 번째 전략이다. 그러나 애석하게도 두 번째 전략에는 치명적인 약점이 있다. MSBuild로 비주얼 스튜디오 솔루션 파일(.sln)을 빌드할 수 있기 때문에 빌드 자동화가 비교적 쉽다. 그런데 MSBuild는 C++ 프로젝트를 빌드할 때 VCBuild를 호출한다. 문제는 VCBuild다. C++ 프로젝트에 /CLR 옵션을 안 붙이는 두 번째 전략을 따르면, VCBuild가 네이티브 C++ 프로젝트인 줄 안다. 그 결과 IDE에선 잘 컴파일되던 코드를 커밋해놓으면, 빌드 서버에 가서 오류가 나는 일이 발생한다.
- 비책! (출처: 미나미가)
-
이 문제를 해결하려면 세 번째 방법을 적용해야 한다. 적어도 현재까지 테스트 결과로는 그렇다. 여태까지 두 번째 전략을 써왔는데, 이제 와서 정반대로 바꿔야한다니 환장할 노릇이다.
베타리더 중 한 분이 요즘 바빠서 블로깅이 뜸하냐고 물어보셨는데, 그런 것만은 아니다. 물론 번역 마무리 작업이 영향을 많이 미치긴 했는데, 다른 이유도 있다. 최근 들어 C++/CLI를 본격적으로 쓰기 시작했고, 미지의 기술(적어도 나한테는)을 적용하여 잘 모르는 시스템을 설하다 보니 블로깅하기가 힘들었다. 뭘 제대로 알아야 글로 풀어내던가 하는데, 삽질의 연속이다보니 글 소재가 없었다. 이 빌드 자동화 팁도 그런 삽질 끝에 알아낸 것이다.
