msvc 외부 솔류션 관리 정책에 대해서

Posted at 2010/02/02 13:10// Posted in msvc
http://www.freebsd.org/ports/

FreeBSD 의 솔류션 포팅 검색 페이지입니다.
만약 devil 이 사용하고 싶다면 검색 상자에 devil 라고 입력하면 됩니다.
그럼 어느 위치에 devil 포트가 존재하는지 나옵니다.

그럼 사용자는 cd /usr/ports/graphics/devil 에 들어가서
make install 만 입력하면 알아서 소스를 받아서 설치하게 됩니다.

...; 사실 이런 수준까지 개인 혹은 작은 회사 수준에서 구축하는건 힘들다고 봅니다.

여기에서 중요하게 체크할만한 부분은 버전 관리입니다.

devil-1.7.8

프로젝트명-버전

살아있는 프로젝트는 새로운 기능에 대한 요구와 버그에 대한 수정으로 인해 계속 버전이 올라가게 됩니다.
문제는 버전업으로 인해 기존 프로젝트가 컴파일이 안되거나 오작동을 할 수 있다는 사실입니다.
즉, 외부 솔류션을 사용한다면 사용하는 다양한 솔류션에 대한 버전을 관리해야 한다는 것이죠.

예를 들어 python 은 python-2.4, python-2.5, python-2.6 은 거쳐오면서 새로운 기능 추가와 버그 수정이
이루어졌지만 큰 틀은 변화가 없기 때문에 대개 큰 문제없이 빌드가 됩니다. 설령 문제가 되더라도 변경된점을
잠깐만 봐도 수정이 가능합니다.

하지만 python-3.0 은 베이스 부분에 매우 큰 변화가 있기 때문에, 적용하기 위해서는 꽤 많은 노력이 필요합니다.
덕분에 아직까지도 python-3.0 프로젝트는 별로 없는 상황이죠.


어쨌든 외부 솔류션을 사용하는 입장에서 해당 프로젝트가 어떻게 진행될지는 모릅니다.
그냥 현재 버전을 알아서 고쳐서 쓸 수도 있겠지만, 언젠가는 새로운 버전의 솔류션을 써야할 때가 다가오게 됩니다.
python-2.6 을 쓰면서 마이너 업그레이드 버전인 python-2.7 과 메이저 업그레이드 버전인 python-3.0 이 동시에
설치 되어 있어야 합니다.

external/python-2.6/bin
external/python-2.6/include
external/python-2.6/libs

external/python-2.7b/bin
external/python-2.7b/include
external/python-2.7b/libs

external/python-3.1/bin
external/python-3.1/include
external/python-3.1/libs

이제 남은 문제는 어떻게 내가 원하는 버전을 사용하느냐 입니다.

솔류션 별로 사용해야 헤더는 python.h 로 동일합니다.


#include <python.h>


쉽게 생각해낼 수 있는 방법은 프로젝트에 추가 INCLUDE 와 LIB 디렉토리를 연결해주는 것입니다.

-I../../../../external/python-2.6/include
-L../../../../external/python-2.6/libs

난감한 점은 몇개가 될지 모르는 상대 경로와 디렉토리의 개수입니다.

사실 솔류션별 디렉토리 개수는 감내할만 한데,
상대 경로가 제일 걸림돌입니다. msvc 에서 단축 상대 경로만 지원해주면 좋을텐데 방버을 잘 모르겠습니다.

$(EXTERN)/python-2.6/include
$(EXTERN)/python-2.6/lib

만약 이런 정도만 지원되면 꽤 쓸만한 솔류션이 될 것으로 보입니다.
단점은 새로운 프로젝트를 만들때마다 조금 손이 많이 가서 귀찮아진다는 것입니다.
아무래도 자동화된 설정 유틸리티를 필요로 하죠~


또 다른 방법은 아예 솔루션 폴더명을 포함시키는 방법입니다.


#include <python-2.6/python.h>

#pragma comment(lib, "python-2.6-x86-vc80-MT.lib")


위의 방법의 장점은
외부 솔류션을 사용하는 입장에서 매우 편하다는 것입니다.
#ifdef - #endif 를 사용해서 다음 버전을 사용해보는 것도 간단합니다.

단점은 외부 솔류션을 일일이 손봐줘야 될 필요가 있다는 것입니다.
사용하는 외부 솔류션이 규모가 조금 클 경우 헤더 교체 작업이 꽤 귀찮아질 수 있습니다.
라이브러리명도 손봐줘야 하죠.

별도 외부 솔류션 관리 인력이 존재한다면 추천할만한 방법입니다.
이올린에 북마크하기(0) 이올린에 추천하기(0)
2010/02/02 13:10 2010/02/02 13:10

msvc 외부 솔루션 관리 필요성에 대해서

Posted at 2010/02/02 12:41// Posted in msvc
요즘 프로젝트를 진행할 때는 외부 솔류션을 사용하는 것이 매우 흔한일입니다.

zlib, tinyxml, devil, boost, expat, freetype, wx 같은 오픈 소스 솔류션 부터
directx, nvidia-texture-tools, fbx 무료 바이너리 솔류션이나
pathengine, speedtree, granny, ipp, mss 같은 유료 바이너리 솔류션까지
하나의 프로젝트에 수십 종류의 크고 작은 외부 솔류션이 포함되게 됩니다.

각 솔류션들을 솔류션 버전, 컴파일러 버전, 쓰레드 모델, CPU 모델 등에 따라 잘 분류해 놓지 않으면
새로운 버전의 솔류션이 나와도 적용하지 못한다던지, 서로 다른 쓰레드 모델(MD, MDd, MT, MTd)간의
충돌로 인한 링크 에러나 런타임 에러가 발생하게 됩니다.

freebsd 나 linux 등에서는 운영체제 레벨에서
다양한 솔류션들을 일관성있게 사용할 수 있도록 지원을 해주는데,
윈도우의 경우는 통합적인 지원이 없는 관계로 각 솔류션들의 배포본 설치에 의존하는 경우가 많아
혼란스러운 경우가 많습니다.

상용 프로젝트의 경우는 미리 빌드된 바이너리를 배포하기 때문에 어느정도 정리가 된 경우가 많지만,
대부분의 오픈소스 프로젝트는 당시 가장 많이 사용되는 visual studio 만 지원하는 경우가 많습니다.
미리 빌드된 바이너리도 MD, MDd 인 경우가 많죠.

boost 정도가  bjam 을 사용해서 다양한 컴파일러/CPU/쓰레드 모델을 지원해주고 있습니다.


요즘 앱스토어가 등장하는 트렌드로 보아
조만간 윈도우에서도 자동화된 솔류션 관리 시스템이 채용되지 않을까 기대하고 있습니다만...
그전까지는 직접 windows ports 시스템을 구축해야 할 필요가 있습니다.







이올린에 북마크하기(0) 이올린에 추천하기(0)
2010/02/02 12:41 2010/02/02 12:41