개요
Earlgrey 라이브러리는 기본적으로 Visual Studio 2008 + Feature Pack 조합이면 별도의 작업을 하지 않아도 빌드가 된다. 그러나 구미에 맞게 외부 라이브러리와 연동하거나 성능 및 기능 옵션을 조정할 수도 있다.
구성 요소
Earlgrey 는 고성능 온라인 게임 서버의 엔진을 제공하고자 시작되었다. 그러므로 그 핵심은 주 프로젝트이자 엔진 라이브러리인 Earlgrey 이다. 하지만 프로젝트 참가자가 그때그때 실험적인 코드를 넣곤 하기 때문에 Earlgrey 외에도 구성요소가 늘어났다. 대표적인 걸 꼽아보자면 다음과 같다.
Earlgrey.Database
단순하게 보자면 ADO (ActiveX Data Objects)의 래퍼 라이브러리이다. ADO는 COM 구현체인 까닭에 그 인터페이스가 C++에서 사용하기에 매우 불편하다. Earlgrey.Database 는 COM 인터페이스를 C++ 에서 사용하기 쉽게 래핑해 제공한다.
Earlgrey.BuildTools
earlgreytrunksrcBuildToolsEarlgrey.BuildTools.sln 솔루션 파일은 실험적인 빌드 도구를 포함한다. 일부는 실제로 Earlgrey 등의 프로젝트에서 사용하며 일부는 순전히 실험적인 기능이다. 아직 구현이 덜 된 까닭에 도입하지 못 하는 코드도 있다. 그러나 걱정할 필요는 없다. 실험적이며 구현조차 덜 된 코드일지라도 빌드는 깨지는 일이 없도록 관리된다. 물론 나중에 Earlgrey가 제공하는 빌드 도구를 제대로 활용하려면 그 구성 요소를 구석구석 알 필요가 있을지 모른다. 하지만 적어도 소스 코드를 빌드하고 돌려보고자 하는 게 전부인 지금 단계에선 그럴 필요까진 없다.
Earlgrey.MSBuild.Tasks
MSBuild 는 마이크로소프트 사가 제공하는 빌드 스크립트 환경이다. Java 개발자라면 Ant를 접해보았거나 들어본 적이 있으리라 생각하는 MSBuild 는 .NET Framework 환경에 대응하는 Ant 라고 생각하면 편하다. 오래 전 C/C++ 환경에 익숙하다면 make 의 현대적인 버전이라 생각하면 편하다. 빌드 스크립트라는 걸 아예 접해본 적이 없다면, 글쎄, 앞으로 알아볼 기회가 충분히 있으리라 생각한다. 당장은 MSBuild 스크립트를 실행하는 법만 알면 된다. 아이폰의 내부 구현을 모른다고 이 최신형 스마트 폰을 즐기는 데는 전혀 지장 없는 것과 다르지 않다.
MSBuild 는 .NET Framework v2.0 부터 배포된다. Earlgrey 는 .NET Framework v4.0 에 대응하는 기능을 제공하는데 Visual Studio 2008 을 설치한 여러분의 머신에는 이미 설치되어 있을 것이다.
그런데 MSBuild 가 기본 제공하는 기능은 실무 환경에선 미흡할 때가 많다. 그래서 Earlgrey.MSBuild.Tasks 는 확장 기능을 제공한다. 그 중 일부 기능은 MSBuild Community Tasks라는 오픈 소스 라이브러리를 이용한다. 뒤에서 살펴보겠지만 이런 까닭에 Earlgrey.MSBuild.Tasks 는 MSBuild Community Tasks 와 함게 배포된다.
Earlgrey.UnityBuild
UnityBuild 는 대규모 C++ 프로젝트를 지원하고자 개발이 시작되었다. 구현이 상당히 진행되었으나 핵심인 엔진 개발에 우선 순위가 밀려 미완성인 채로 남아 있다. 조만간 마저 끝내고 엔진 프로젝트인 Earlgrey 에 도입하고자 한다.
Unity Build 참고 자료
단위 테스트
성숙한 코드를 가려내는 기준
비주얼 스튜디오 솔루션 파일 Earlgrey.sln 에 포함된 프로젝트의 이름을 가만 살펴보면 ~Test 인 경우가 눈에 띈다. 이러한 프로젝트는 대체로 단위 테스트 프로젝트이다. 예외적으로 gtest만이 단위 테스트 프로젝트가 아니고 단위 테스트 프레임워크인 Google Test이다. 이마저도 단위 테스트에 쓰인다는 점은 공통적이다. Earlgrey는 여전히 현재 진행형이고 실험적인 코드가 많다. 공사 현장이나 다름 없어서 어느 게 쓸만한 지 파악하기 힘들 수 있다. 그럴 땐 해당 프로젝트에 대응하는 단위 테스트 프로젝트가 있는지 확인하면 된다. 성숙한 코드는 모두 단위 테스트가 포함됐다. 물론 단위 테스트가 있다고 해서 모두 성숙한 코드는 아니지만 적어도 이러한 지침이 구분하는 데 도움이 되긴 할 것이다.
Earlgrey.sln 의 단위 테스트
Earlgrey.sln 에 속한 주 프로젝트와 그에 대응하는 단위 테스트 프로젝트를 정리하면 다음과 같다.
| 주 프로젝트 | 단위 테스트 프로젝트 |
|---|---|
| Earlgrey | Earlgrey.Test |
| Earlgrey.Database | Earlgrey.Database.Test |
Earlgrey.BuildTools.sln 의 단위 테스트
Earlgrey.sln에 비해 Earlgrey.BuildTools.sln 에는 유독 단위 테스트 프로젝트가 많다. 실은 단위 테스트 프로젝트가 많다기 보다 프로젝트 수가 많아서 그만큼 단위 테스트 프로젝트가 많을 뿐이다. 그러나 첫 인상과 달리 주 엔진보다 빌드 도구가 규모가 큰 건 아니다. 개발 편의를 위해 외부 라이브러리를 솔루션에 포함시켰고 그런 까닭에 방대해 보일 뿐이다. 여러분이 진정으로 관심을 가질 부분은 외부 라이브러리가 아닌 Earlgrey 프로젝트의 코드일 것이다. 또한 일부 프로젝트와 그 단위 테스트는 핵심 기능을 제공하는 부분이 아니므로 크게 관심을 갖지 않아도 된다. 그러므로 살펴볼 내용도 생각만큼 많지는 않다.
| 주 프로젝트 | 단위 테스트 프로젝트 |
|---|---|
| MSBuild.Earlgrey.Tasks | MSBuild.Earlgrey.Tasks.Tests |
| UnityBuild. | UnityBuild.Tests |
개발 환경
EarlGrey 커미터는 대체로 Visual Studio 2008 Professional Edition 을 사용한다. Express Edition 에서도 빌드가 될 것이라 생각하나 이를 보장하진 않는다. Visual Studio 2005 는 지원하지 않는데 이는 Visual Studio 2008 Feature Pack 에 구현된 TR1 구현을 사용하기 때문이다. std::tr1::shared_ptr 같은 스마트 포인터가 Feature Pack 에서 가져와 쓰는 기능이다.
EarlGrey 에는 실험적인 코드가 곳곳에 있다. Earlgrey.Database 가 그러한 사례에 속한다. 이 프로젝트에 대한 단위 테스트를 수행하는 Earlgrey.Database.Tests 란 프로젝트가 제대로 작동하려면t 로컬 머신에 SQL Server 2005 Express Edition 이 설치되어야 한다. 다행히 Visual Studio 2008 을 설치할 때 기본 옵션으로 선택된다.
여러분이 Visual Studio 2008 의 개발 환경에 익숙하다면 필요한 구성 요소를 각자의 취향에 맞춰 설치하면 된다. 그러나 우리가 권장하는 설치 절차는 다음과 같다.
- Visual Studio 2008 Professional Edition 을 전체 설치한다.
- 로컬 머신에 설치된 SQL Express Edition 인스턴스에 접속해본다. .SQLExpress 를 주소로 잡고 윈도우 도메인 계정으로 로그인한다. 여러분의 윈도우 사용자 계정으로 데이터베이스를 생성하고 삭제할 수 있는지 확인한다. 만약 안 된다면 sa (sysadmin) 권한을 부여한다.
- Visual Studio 2008 의 Service Pack 1 을 설치한다. SP1 에 Feature Pack 이 포함된다.
서브버전 체크아웃/업데이트
EarlGrey 의 소스코드는 구글 코드를 통해 제공된다. http://github.com/andromedarabbit/earlgrey/source/checkout에 접속하면 저장소 주소와 svn 명령어 예제가 보인다. 프로젝트 참가자로써 커밋 권한이 있다면 자신의 계정과 암호로 체크아웃 받으면 된다.
svn checkout https://earlgrey.googlecode.com/svn/trunk/ LocalDirName --username MyID
커미터가 아니고 일반 사용자라면 계정 정보를 입력하지 않은 채 내려 받으면 된다. 처음에 일반 사용자 권한으로 내려 받았더라도 걱정할 필요 없다. 소스 코드를 변경하고 체크인하려고 하면 그때 가서 다시 계정 정보를 요구할 것이다.
svn checkout https://earlgrey.googlecode.com/svn/trunk/ LocalDirName
그런데 계정 정보를 입력하고/입력하지 않고 Earlgrey 소스코드를 내려 받다 보면 중간쯤 한번 더 사용자 계정 정보를 물어본다. 이는 외부 라이브러리인 MSBuild.Community.Tasks1 를 참조하기 때문이다(svn:external). 이때 사용자 이름은 guest 로 하고 암호는 비워놓으면 된다.
요약: 소스 코드 내려 받기
- 서브버전 저장소 https://earlgrey.googlecode.com/svn/trunk/ 에서 소스 코드를 체크아웃 받는다.
- 커미터라면 이때 계정 정보를 입력해도 되고 나중에 해도 된다.
- 체크아웃 받는 중간에 사용자 계정 정보를 한번 더 물어본다. 사용자 이름은 guest로 하고 암호는 비운 채 엔터를 치면 된다.
Earlgrey 엔진 빌드하기
첫 빌드
Earlgrey 의 모든 구성요소가 올바르게 작동하려면 최소한 한번은 Visual Studio 가 아닌 MSBuild 스크립트를 이용해야 한다. 빌드 스크립트를 돌리는 이유야 여럿 있다. 하지만 핵심적인 이유는 데이터베이스 단위 테스트에 쓸 테이블과 레코드를 로컬 SQL 서버 인스턴스에 생성해야 하기 때문이다.
자, 빌드하기로 마음 먹었으면 명령 줄(cmd.exe)을 열고 earlgreytrunksrc 폴더로 간다. UAC (User Account Control, 사용자 계정 컨트롤) 이 도입된 Windows Vista 나 Windows 7 를 사용하는 개발자라면 명령 줄을 관리자 권한으로 실행한다. 레지스트리를 조작하는 등 관리자 권한이 필요한 단위 테스트가 있기 때문이다.
이제 32 비트 바이너리를 빌드할지, 64비트 바이너리를 빌드할 것인지 선택한다. 32비트 빌드를 할 때는 MSBuild_Win32.bat를 이용하고, 64비트 빌드를 할 때는 MSBuild_x64.bat를 실행한다는 점만 다르다. 이 두 개의 배치 파일은 .NET Framework 와 함께 배포되는 msbuild.exe 파일의 래퍼 역할을 한다. 배치 파일을 텍스트 편집기로 열어보면,
REM MSBuild_Win32.bat @echo off SETLOCAL call "%VS90COMNTOOLS%....VCvcvarsall.bat" x86 call "C:WINDOWSMicrosoft.NETFrameworkv3.5msbuild.exe" %* SET ERR_LEVEL=%errorlevel% exit /b %ERR_LEVEL%
REM MSBuild_x64.bat @echo off SETLOCAL call "%VS90COMNTOOLS%....VCvcvarsall.bat" x64 call "C:WINDOWSMicrosoft.NETFramework64v3.5msbuild.exe" %* SET ERR_LEVEL=%errorlevel% exit /b %ERR_LEVEL%
간단히 설명하자면 32비트 또는 64비트 빌드에 맞는 환경을 구성하고 알맞는 MSBuild 바이너리를 실행한다. 뒤에 자세히 설명할 기회가 있으리라 보고 당장은 이 배치 스크립트로 빌드하는 법만 알아보자.
MSBuild_Win32.bat
타이핑 수고를 가장 적게 들이는 동시에 가장 자주 쓰게 될 명령일 것이다. 이 명령은 기본 구성 값을 이용해 빌드하는데 사람이 구성 값을 일일이 지정한다면 다음과 같은 형태가 된다.
MSBuild_Win32.bat msbuild.xml /t:Build /p:Configuration=Debug
꽤 길다. /t, /p 로 시작하는 스위치가 튀어나오고 대체 무슨 뜻인지 모르겠다. 프로그래밍 분야가 으레 그렇듯 알고 나면 별 게 없다. 무엇보다 반가운 소식은 열의 아홉은 MSBuild_Win32.bat라는 명령으로 충분하단 것이다. 멀미 나게 긴 명령어를 쓸 일은 많지 않다. 하지만 바로 그 열의 한번 꼴로 발생하는 상황에 대비해 빌드 옵션을 멀미나지 않게 하나씩 차근차근 알아보자.
MSBuild_Win32.bat msbuild.xml
msbuild.xml은 빌드 스크립트 파일의 이름이다. 이 파일에 있는 기능을 이용하겠다는 뜻이다. 나중에 설명할 일이 있겠지만 빌드 서버인 CruiseControl .NET 에서는 msbuild.xml 이 아닌 msbuild-ci.xml 을 불러다 추가 작업을 한다. 처음 예제에서 빌드 스크립트 파일의 이름을 생략해도 작동했던 이유는 아주 간단하다. 인자로 파일 이름을 지정하지 않으면 msbuild.exe 가 msbuild.xml 라는 파일이 있는지 직접 확인하기 때문이다.
MSBuild_Win32.bat msbuild.xml /t:Rebuild
MSBuild 스크립트에는 일반 프로그래밍 언어의 함수에 해당하는 작업(Task)라는 게 있다. /t: 스위치는 어느 함수를 실행할지 지정할 때 쓴다. 첫 예제에선 이 스위치를 빼먹어도 잘 작동했는데 이는 msbuild.xml 에 기본 작업(DefaultTargets)을 지정해 놓았기 때문이다.
<?xml version="1.0" encoding="utf-8" ?>
<Project
DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- 중략...... -->
</Preject>
MSBuild_Win32.bat msbuild.xml /t:Rebuild /p:Configuration=Debug
여러분이 프로젝트 Earlgrey 에 직접 참가하는 경우, 그러니까 프로젝트 관리자나 커미터로 활동하지 않는다면 이것보다 복잡한 옵션을 쓸 일은 거의 없을 것이다. 이전 명령에 비교해 달라진 점은 /p:Configuration=Debug라는 인자가 추가된 것이다. /p:는 빌드 스크립트에 정의된 속성(Property, 변수라 생각하면 됨)의 값을 지정할 때 쓴다. 이 경우엔 Configuration 변수의 값을 Debug 로 지정하여 Debug 빌드를 하도록 강제한다.
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
</PropertyGroup>
trunk/src/msbuild.xml 의 주요 옵션
플랫폼 (Platform)
* WIN32 / x86 빌드 : MSBuild_Win32.bat
* x64 빌드 : MSBuild_x64.bat구성 (Configuration)
* Debug : /p:Configuration=Debug
* Release : /p:Configuration=Release작업 (Targets)
* 빌드 : /t:Build
* 다시 빌드 : /t:Rebuild
* 정리 : /t:Clean
* 단위 테스트: /t:TestAlone
첫 단위 테스트
앞서의 설명에 따라 빌드를 했다면 Earlgrey.Test.exe, Earlgrey.Database.Test.exe 등 단위 테스트 바이너리가 생성되었을 것이다. 필요한 파일이 준비되었으니 크게 두 가지 일이 남았다.
- 단위 테스트할 테이블과 레코드 등을 로컬 데이터베이스에 준비한다.
- 단위 테스트를 수행하고 결과를 확인한다.
이 작업은 모두 빌드 스크립트에서 자동으로 해준다. 빌드할 때와 똑같은 명령을 이용하되 작업(Target) 이름만 TestAlone로 지정한다.
MSBuild_x64.bat msbuild.xml /t:TestAlone /p:Configuration=Debug
TestAlone은 단위 테스트 전에 Visual Studio 2008을 설치할 때 로컬 머신에 설치되었을 SQL Server 2005 Express 인스턴스에 접속한다(서버 주소: .SQLEXPRESS). 그러고 나서 단위 테스트에 필요한 테이블 등을 생성한다. 단위 테스트 중에는 그 과정을 명령 창에 보여주고, 프로그램이 종료될 때 XML 파일에 결과를 저장한다.
그런데 Build 후에 직접 TestAlone 을 실행해야 하는 과정이 번거롭지 않은가? 빌드 스크립트를 두 번이나 실행해야 하다니! 실은 Build 작업이 끝나고 TestAlone을 자동으로 수행하게 스크립트를 짤 수도 있다. 하지만 그렇게 되면 소스 코드를 자주 바꾸는 로컬 개발시 되려 불편할지 모른다. 한 줄 고쳤을 뿐이고 개발을 마친 후에 단위 테스트를 실행해도 되는데 매번 단위 테스트가 끝나길 기다린다면 어떤 기분이겠는가? 짜증나지 않을까?
로컬에선 훨씬 편하게 개발이 가능하다. 단위 테스트가 끝나도 이때 사용한 테이블과 데이터는 남기 때문에 TestAlone 을 한번 실행한 후에는 빌드 스크립트를 쓰지 않아도 된다. Visual Studio 에서 바로 단위 테스트 프로젝트를 실행하면 된다. 물론 이렇게 복잡한 과정을 거치는 건 Earlgrey.Database 때문이다. Earlgrey 프로젝트에 관련된 점만 테스트해볼 생각이면 TestAlone 은 신경 쓰지 말고 Visual Studio 로 들어가 곧장 Earlgrey.Tests를 실행하면 된다.
일상적인 단위 테스트
Earlgrey.Test 에는 몇 가지 짜증을 유발할 만한 단위 테스트가 포함되었다.
- 메모리 성능 테스트: CPU 사용률이 치솟고 오래 걸린다.
- 이메일 발송 테스트: 테스트 이메일이 발송되어 이메일 계정에 스팸처럼 쌓일 염려가 있다.
이런 문제를 겪지 않으려면 Earlgre.Test.exe 실행시 명령인자를 다음과 같이 적는다.
C:earlgreytrunksrcWin32-Debugbin> Earlgrey.Test.exe --gtest_filter=-*Performance*:*Mail*
이는 성능(Performance) 테스트와 이메일(Mail) 테스트를 하지 말라는 뜻이다. 메모리 할당 전략별로 성능 비교를 하는 테스트는 CPU 와 메모리를 과도하게 사용하는 경향이 있다. 충돌이 났을 때 이메일로 덤프 파일을 전달하는 테스트 등도 있는데, 단위 테스트를 할 때마다 이메일을 서너 통씩 받는다고 생각하면 기분이 과히 좋진 않을 것이다.
Earlgrey 빌드 도구 빌드하기
일상적인 빌드
Earlgrey의 자체 빌드 도구는 earlgrey/trunk/src/BuildTools 안에 있으며 Earlgrey.BuildTools.sln와 msbuild*.xml 파일이 빌드 도구를 빌드하는 시작점이다. 빌드 도구를 빌드한다니 말이 웃긴데 실은 엔진 라이브러리나 빌드 도구나 크게 차이가 없다. 엔진과 달리 네이티브 C++ 이 아닌 C# 위주(현시점에선 빌드 스크립트를 제외한 100%)로 작성됐다는 점만 다르다.
빌드하는 법은 언제나처럼 간단하다. Earlgrey.BuildTools.sln 을 열어서 Visual Studio 에서 빌드해도 좋고, MSBuild 스크립트를 실행해도 된다. 둘 다 큰 차이는 없지만 MSBuild 를 사용하면 편리할 뿐더러 배포에 필요한 파일만 따로 걸러주는 일도 한다. 배포에 관해선 뒤에서 알아보기로 하고 여기선 빌드 스크립트를 쓰는 방법만 알아보자.
기본적인 사용법은 엔진이나 빌드 도구나 다를 게 없다.
MSBuild_Win32.bat msbuild.xml
인자를 입력하지 않으면 아래와 같은 명령과 동일하게 해석한다. 엔진을 빌드할 때와 다르지 않다. 적어도 earlgrey/trunk/src/BuildTools/msbuild.xml 파일 만큼은 earlgrey/trunk/src/msbuild.xml와 거진 동일한 방식으로 사용 가능하다.
MSBuild_Win32.bat msbuild.xml /t:Build /p:Configuration=Debug
주요 작업(Target)도 엔진을 빌드할 때와 거의 똑같다. 유일하게 다른 점은 플랫폼 값이다. MSBuild_Win32.bat 를 쓰든 MSBuild_x64.bat 를 이용하든 결과물이 같다. 어느 경우라도 .NET Framework의 Any CPU 플랫폼으로 빌드하기 때문이다.
trunk/src/BuildTools/msbuild.xml 의 주요 옵션
플랫폼 (Platform)
- Any CPU
구성 (Configuration)
- Debug : /p:Configuration=Debug
- Release : /p:Configuration=Release
작업 (Targets)
- 빌드 : /t:Build
- 다시 빌드 : /t:Rebuild
- 정리 : /t:Clean
- 단위 테스트: /t:TestAlone
Earlgrey 엔진: 고급 빌드
배포하기
현재는 지원하지 않는다.2
빌드 자동화 서버와 연동하기
프로젝트 Earlgrey 에선 빌드 자동화 서버를 도입하여 소스 코드의 변경이 있을 때마다 빌드 머신에서 빌드와 단위 테스트를 수행한다. 만약 빌드나 단위 테스트가 깨지면 프로젝트 참가자에게 이메일로 그 사실을 전달한다. 자세한 이야기는 뒤에 하기로 하고 여기선 프로젝트에서 사용하는 빌드 서버인 CruiseControl .NET에서 MSBuild 스크립트를 어떻게 사용하는지 알아본다.
먼저, 프로젝트에서 실제로 사용하는 CruiseControl .NET 의 구성 파일을 살펴본다.
<!-- trunkvendorBuildToolCruiseControl.NETv1.5.7256.1serverccnet.config 중에서 -->
<msbuild>
<executable>MSBuild_x64.bat</executable>
<workingDirectory>D:Build Workspaceearlgrey-x64-releasesrc</workingDirectory>
<projectFile>msbuild-ci.xml</projectFile>
<buildArgs>/noconsolelogger /p:Configuration=Release /v:m</buildArgs>
<targets>BuildForCI</targets>
<timeout>12000</timeout>
<logger>ThoughtWorks.CruiseControl.MsBuild.XmlLogger,C:Program Files (x86)CruiseControl.NETserverThoughtWorks.CruiseControl.MSBuild.dll</logger>
</msbuild>
이 예제에선 Debug|Win32 구성 플랫폼 값으로 엔진을 빌드한다. 작업(Target)이 Build에서 BuildForCI로 바뀐 점만 제외하면 전과 달라지지 않았다. 다만 빌드 스크립트 내부에는 다시 빌드가 필요한 상황인지 스스로 판단한지를 판단하고, 단위 테스트를 수행하는 등의 추가 작업이 이뤄진다. 상세한 작업 내역은 프로젝트의 진행 상황과 필요에 따라 매번 조정된다. 이 글을 읽는 시점엔 더 많은 일을 할 수도, 아니면 반대로 더 적은 일을 할 수도 있다.
빌드 서버용 빌드 스크립트에서 추가로 도입된 매개변수, 그러니까 속성 값은 단 하나 이다. CCNetBuildCondition는 CruiseControl .NET 이 스스로 값을 만들어 제공한다. 이 값은 어떤 상황이 벌어져서 이 빌드를 수행하게 됐는지를 알려준다. 현재로선 두 가지 값이 가능하다.
- ForceBuild
- IfModificationExists
ForceBuild는 웹 인터페이스 등에서 사용자가 빌드를 수행하라고 직접 지시를 내렸음을 뜻한다. 이 경우는 무언가 문제가 발생했다고 판단하여 다시 빌드한다. IfModificationExists는 누군가 소스 코드를 커밋했음을 뜻한다. 일상적인 상황이므로 빌드 시간을 단축하고 피드백을 빨리 주기 위해 정리(Clean)하지 않고 바로 빌드한다.
trunk/src/msbuild-ci.xml 의 주요 옵션
구성 (Configuration)
- Debug : /p:Configuration=Debug
- Release : /p:Configuration=Release
작업 (Targets)
- 빌드 : /t:BuildForCI
- 정리 : /t:CleanForCI
CruseControl .NET 연동
- 소스 코드 변경 여부: /p:CCNetBuildCondition=IfModificationExists
Boost 라이브러리 이용하기
Earlgrey 의 일부 기능은 Boost 라이브러리의 구현물로 대체 가능하다. 대표적인 것이 EARLGREY_NUMERIC_CAST이다.
