간단한 Windows API / Windows CE API 개발 환경 (2)

앞서 vcvars32.bat이나 wcearmv4i.bat 등으로 최소한의 빌드 환경을 구축할 수 있었다. 한편 cl.exe나 clarm.exe의 입출력을 제어하는 것만으로는 부족할 때가 있는데, 라이브러리를 사용하게 되면 거의 항상 그렇다. 마이크로소프트의 빌드 시스템과 라이브러리는 20년에 가까운 시간 동안 자신들의 엄격한 호환성을 지키며 엄청나게 복잡하게 발전해 왔고, IDE를 통하지 않으면 프로젝트를 잘 진행하기 어렵게 되었다. 물론 그 IDE는 솔직히 다른 IDE와는 비교가 안 될 정도로 멋지고 강력하지만, 아쉬운 건 어쩔 수 없다.

GNU 빌드 시스템과 MS 빌드 시스템을 묶은 것들도 유명하다. CMake나 Qt의 moc인 qmake 등이 그것이다. 비록 지향점은 다르지만 (CMake는 보다 native shell 친화적이고 별도의 라이브러리를 사용하지 않는다.) 이들은 양쪽의 빌드 시스템을 이해하고 새로운 언어로 구성하는 데 성공했다. 양쪽의 빌드 시스템에 모두 관심이 있다면 이들 프로젝트를 참고해 보거나 채택하는 것도 괜찮을 것이다.

물론 난 이들 전처리, 전처리, 전처리에 질렸다! 게다가 이들 멀티플랫폼은 때때로 너무 쉽고, 종종 타깃 플랫폼을 전혀 이해하지 못하며, 가끔은 프로그램의 본질을 망친다. 이 때문에 여러 플랫폼을 대상으로 개발을 하더라도 플랫폼에 따라 수동으로 해야 하는 부분이 있고, 네이티브에 맞춰야 할 것도 있다. 애석하게도 이런 작업에 나쁘지 않은 MSYS/MinGW는 Windows CE나 .NET, Windows SDK, WinRT 등에 별 관심이 없다. 한편 MS는 모든 오토메이션을 VS IDE에 몰아넣었고, VC6를 넘어가면서 사실상 터미널에서 IDE 기능을 가져다 작업할 수가 없게 되었다.

우선 MS 컴파일러와 GCC의 이중 체제를 유지하고 어떻게 GNU 빌드 시스템으로 통합할지를 고민해 보자. 일단 zlib처럼 Makefile.gcc와 Makefile.msc를 따로 만드는 정도면 괜찮지 않을까. 

HN.zip

HellO.zip

HN.zip과 Hello.zip은 각각 eMbedded Visual C++ 4.0에서 WCE400 STANDARDSDK 옵션으로, Visual Studio 9.0에서 증분 링크 옵션을 없애고 빌드한 워크스페이스 폴더의 압축 결과물이다. eVC4의 루트 폴더에는 원래 {ProjectName}.VCL 파일로 빌드 로그가 남겨지는데 이를 .DBG.VCL과 .REL.VCL로 리네임해 놓았다. VS9는 소스 폴더에 BuildLog.htm을 생성하므로 이를 참고할 수 있다. 두 프로젝트가 같은 내용은 아니다.

사실 비교를 하겠다면 eVC4(WCE400)와 VC6(Win32)를 보고, VS9에서 Win32와 WCE500를 보는 게 설득력이 있지만, MSVCRT야 MinGW가 잘 받쳐 주고 있고, VS9-WCE500은 이미 내가 실패한 전적이 있어서 미뤄 둔다.