프로그래머의 일상: 2008년 5월 29일

빌드 서버 설정 삽질기

남는 듀얼 코어 머신(Conroe 6600) 한 대를 빌드 머신으로 쓰기로 하고 점심 먹고 설정을 시작.

  1. 장비 소유자를 변경하고, MAC 주소 발급을 기다림
  2. 뭔가 부팅이 되었다 말았다해서 일단 불필요해보이는 것들 — 어쨰서인지 달려있는 PC4200 메모리 1기가와 DVD드라이브 떼버렸음. 그래도 6400U로 2기가 남아있음 — 을 제거. 부팅은 잘되네
  3. MAC 주소 발급되자 필요한 것들을 네트웍 인스톨 시작
  4. VS 2005 SP1 설치, python, cruisecontrol.net, IIS, … 및 각종 GNU binutil 설치[1]
  5. CruiseControl.net이 뜨길 거부한다. IIS설정 문제는 아니었고, 어째서인지 VS 2005가 설치되고 나니 잘 뜸. 이유가 뭘까…
  6. VS 2005 서비스 팩이 설치되기를 거부. 맞는 버젼이 없다네…
  7. 일단 빌드 머신으로 제대로 동작하나 테스트 시작. 빌드가 되긴하는데 전부 다 되는게 아니라 일부 라이브러리가 빌드 에러를 내뱉는다
  8. 재부팅
  9. VS 2005 서비스팩 설치됨. 대체 재부팅에 무슨 마력이… 이것도 원인이 뭘까 -_-;;;
  10. 빌드 안되던 녀석들도 빌드 성공

여기까지 대략 3시간 반 -_-;;

프레스캇 (intel 640) -> 콘로 6600으로 바뀌었고, HDD도 IDE->SATA2, 램도 두 배 상승. 덕분에 일부 빌드는 3배나 빨리 빌드되고, 대부분 2배 이상 빨라졌음. 이러니 CI나 빌드 자동화 얘기하는 책에선 빌드 머신에 돈 좀 들이라고 말하는건가… 피드백 받는 주기가 훨씬 빨라졌으니…[2]

소스코드 인코딩 문제 발생

빌드는 되는데 일부 테스트가 실패한다 — 바꾼게 없는데 Orz.

테스트 로그를 보니 문자열이 깨져서 생기는 문제 같았다 — wide char로 선언하는 L”…” 꼴이 제대로 해석이 안된듯. 기존 빌드 머신이랑 차이를 비교해보니 locale이 다르네. 둘 다 windows server 2003 ENU지만 하나는 한국어 로케일, 하나는 영문 로케일(후자가 새 머신). 그래서 아예 저 문자열을 wchar_t str[] = { 0xd55c, 0xae00, 0x00 };  하는 식으로 때웠음. 근데 이것도 좀 귀찮은 일이라, 저걸 가지고 assertEqual 류 호출 할 때는 L”\u0xd55c” 하는 식으로 비교했다… 아무래도 소스코드 인코딩이 UHC였다가 latin1으로 해석해서 생긴 문제였던 것 같다.

근데 이게 좀 짜증나는게 VS 2003에서는 인코딩 자체를 상당히 명시적으로 주고 그러기 쉬운데, VS2005는 또 그게 아니거든 Orz. 언제 회사에서 MSDN가지고 VS2008을 써봐야할듯…

  1. 자동화 면에선 윈도우에 있는 툴보다 GNU binutil이 익숙해지면 훨씬 쓰기 쉽고, 자동화(=커맨드라인)도 쉽다는 느낌… []
  2. 여담이지만 UnitTest가 도는 속도도 빨라져서 좋다…. []

Published by

rein

나는 ...

Leave a Reply