보통 방학때 포트란이라던지 c언어라던지 컴퓨터언어를 가르치는 강좌가 개설되곤 하기도 했는데 리스트라던지 프롤로그라던지 인공지능관련이나 컴퓨터그래픽 관련 전문 과목은 아마 달랑 한 과목정도 일듯하다. 즉 개인이 알아서 공부해야 되는게 많다는 뜻일듯.. 사실 컴퓨터지식이 많다는 해커는 누가 가르치는 것도 아니다.. 이게 인생이다.. ㅋㅋ
자 이제 현실로 돌아와서 컴퓨터 프로그래밍을 배울려면 가장 필요한 것이 물론 컴퓨터이다. 그리고 개발툴이 필요하다. 사실 소프트웨어도 사용되는 분야에 따라 상당히 다양하다. 운영체제, 개발툴, 멀티미디어관련, 네트워킹관련, 보안관련, 데이타베이스관련, 게임관련, 그리고 연구나 산업용 전문툴까지.. 즉 하나의 지식으로 소프트산업을 보면 안되고 학문에서 자주 이야기 되는 학문융합의 영역에서 나오는 소프트웨어들이 많다. 거기에 취미활동가까지..
그리고 무엇보다 영어실력이 필요하다. 인터넷은 커뮤티케이션의 세상이다 보니 국제언어인 영어의 세상이다. 대부분의 정보가 영어로 되어있다. 대부분의 소프트웨어 매뉴얼도 영어로 된 경우가 많은데 매뉴얼 한번 읽어보면 전문가가 될 수 있는 것을 영어를 모른다는 이유하나 때문에 어디 게시판이나 카페같은데서 일일히 물어보고 하는 초보티를 내야 되는것이다. 물론 한국에서 최초 개발된 것이 있다면 한국어를 배워야 보다 정보에 가까워 질 수 있고 일본에서 최초로 개발되었다면 일본어를 배워야 보다 그 정보에 가까워 지겠지만 또 국가별로 정보공개에 사람들이 적극적인 사람들이 있고 그렇지 못한 국가가 있다.. 영어권이 정보가 많은 이유는 이런 정보공유정신도 좀 영향이 있다. 그 밖에 다른 나라는 최초 연구를 목적으로 인터넷을 개발한 영문권과 달리 상업적 목적을 이유로 인터넷이 발전한 경우가 많다. 그런 인프라의 차이도 공유된 정보의 양과 질이 언어별로 달라지게 하는 한 요인이 된다. 영어를 배워야 공유된 양질의 정보에 접속하기 쉬운 이유중 하나다. 영어를 모르면 앞으로 소개할 다음 글중 일부 내용은 도움이 안될 수도 있다.
마지막으로 보통 다른 목적으로 컴퓨터를 이용할 때 보다 더 용량이 큰 하드디스크 공간이 필요하다. 보통 압축프로그램이 4배가 5배의 압축효율을 보이는데 텍스트로 된 소스프로그램이 컴파일이 되서 바이너리 파일이 되면 보통 10배이상의 압축효과가 있다. 이건 무슨 이야기인가 하면 사이즈가 1MB 정도되는 프로그램을 만들때 그 프로그램을 만들기위해 사용되는 프로그램소스가 10MB이상이 될 수 있다는 이야기다. 소스를 가지고 작업할 때 여기저기 라이브러리 소스를 깔아놓고 작업을 할려면 많은 하드 공간이 필요해 진다는 이야기이다. 게다가 컴파일 작업시 중간에 생성되는 오프젝트까지 치면 100배이상까지 공간을 잡어먹기도 한다. 이건 하나의 프로그램이 그 프로그램소스만 쓰는게 아니라 그 프로그램을 만들기 위해 다른 라이브러리들을 호출해서 쓰는데 그 라이브러리의 많은 루틴중 단 한개만 쓴다고 해도 그 라이브러리를 다 설치해서 컴파일해야 쓸수 있는 라이브러리를 얻게 되기 때문에 이런 라이브러리들이 차지하는 공간이 많기 때문이기도 하다. 게다가 호출함수에 대해 일일히 다 공부해서 외울수도 없고 금방 찾아볼 수 있는 API매뉴얼도 여기저기 설치해서 보면서 프로그램을 하다보면 하드공간이 넉넉할 수록 좋다.
예를 들면 Luxrender (http://www.luxrender.net/) 라고 Maxwell (http://www.maxwellrender.com/)
과 비슷한 오픈소스의 물리렌더링 프로그램이 있는데 지금 내 하드에서 5M정도의 프로그램파일을 생성하기 위해 사용된 공간이 소스와 생성된 파일들을 포함해 약 800MB이다.
가장 쉽게 개발환경을 접할 수 있는건 윈도우보다는 리눅스가 상당히 좋다. 리눅스를 깔고 컴파일하고 하는거 자체가 완전히 소프트웨어 개발환경이라고 볼 수 있다. 앞에서 개발툴이 필요하다고 했지만 보통 이런 소프트웨어를 작성하는데 컴퓨터 언어라는 것이 필요한데 초기에 IBM PC XT같은 것이 있을때 주로 베이직같은 프로그램이 내장되어 그런 것으로 프로그램을 작성할 수 있었는데 실제 대부분의 프로그램은 C나 C++라는 것으로 많이 개발이 된다. 수년전만 해도 PC사서 뭐 좀 만들어 볼려고 해도 이 C 프로그램이 마이크로 소프트사의 컴파일러는 돈을 주고 사야만 구입이 가능했다. 리눅스가 좋다는 것이 이런 개발툴이 운영체제와 함께 다 같이 제공된다는 점이었다. 즉 뭐 좀 프로그램을 쓸려면 만들어 쓰지 말고 그냥 돈주고 사서 쓰라는 분위기가 리눅스같은 유닉스계에 비해 윈도우를 쓰는 사용자에 대한 마이크로소프트사의 배려(?)였던 것이다.
몇년전 리눅스가 윈도우시장을 공략한다는 뉴스처럼 리눅스 붐이 인 적이 있는데 그 후 마이크로 소프트사도 좀 오픈소스계의 공격에 처하고 그 이후에 마이크로소프트사의 주력 C,C++ 컴파일러인 비쥬얼 스튜디오 제품도 상용과 별도로 성능을 낮춘 일반 무료 배포판을 제공하기 시작했지만 수년전만 해도 첨으로 텔넷같은거 하면서 유닉스계에 이런 GCC같은 오픈소스기반의 툴들이 있다는 것과 윈도우의 개발환경을 비교해 보면서 유닉스는 연구용 OS, 윈도우는 장사꾼들을 위한 OS라는 생각에 치를 떨었던 적도 있었으니.. 지금와서 윈도우도 유닉스나 비슷하게 개발환경이 좋게 된데에는 솔직히 말해서 불법공유의 힘의 컸다고 생각이 들 정도다.. 개인적으로 기본적인 C컴파일러는 OS랑 같이 딸려와야 정상이라고 생각이 드니.. 개발툴도 없이 컴퓨터를 뭐에 쓰란건지..
하여간 기초적으로 이 C언어는 좀 알아야 된다. 과거에는 하드웨어적인 조작을 위해 어셈블리언어까지 어느정도 알야야 하고 지금도 알면 좋지만 요즘은 하드웨어쪽이 워낙 복잡해 졌기 때문에 그쪽을 다루는 건 소수 전문가들한테 맞기고 일반인은 그들이 만든 드라이버나 쓸 줄 알면 된다. 과거에는 컴퓨터 성능이 많이 딸렸기 때문에 가볍고 빠른 C가 C++언어에 비해 많이 쓰였다. 사실 C로 C++컴파일러를 만들 수 있는 것처럼 C로 C++처럼 프로그래밍하는 파라다임을 구축하는 것도 어렵진 않지만 요즘은 컴퓨터 성능이 좋아지면서 C++로 짠 소스들이 많고 객체로 프로그래밍하는게 상당히 편하기 때문에 요즘은 C++가 대세가 되는 분위기다. 물론 컴파일러에는 전통적인 베이직이나 포트란이외에도 상당히 많은 종류가 있다. Functional Programming이라던지 Genetic Programming이라던지 이 쪽도 종류가 무지 많다. http://dir.yahoo.com/Computers_and_Internet/Programming_and_Development/Languages/
에 보면 현재 연구되는 언어들이 뭐가 있나 거의 대부분 나온다. 야후가 처음 나올 때는 이 디렉토리 서비스가 꽤 좋았고 최신 정보가 많았는데 요즘은 상당히 안 좋아졌긴 하다. 요즘은 고글이 더 좋은 듯..
http://directory.google.com/Top/Computers/Programming/Languages/ 나도 인공지능언어같은데 관심이 많아서 이런 디렉토리 링크를 통해 어떤 컴퓨터 언어가 있나 찾아보던 때도 있었다. 초기 야후의 디렉토리서비스에 비해 요즘은 웹이 발전하면서 웹의 검색에 자사 홈페이지를 링크시킬려고 하는 회사나 단체가 워낙 많아지다 보니 정작 초보자들을 위한 링크를 발견하는건 초기보다 쉽지 않다. 과거 usenet을 이용하던 시절에는 FAQ라는 문서가 언어별 usenet 포스팅에 주기적으로 올라오고 그걸 관리하는 사람들도 있었는데 특히 리스프나 프롤로그같은 인공지능언어의 FAQ에는 현재 사용되는 무료와 상용프로그램 정보가 잘 정리되어 있어 유용했다.
하여간 여기선 윈도우를 쓰는 중생들이 대부분이라 생각하고 (사실 리눅스쓸 정도면 혼자서 알아서 잘 알 테니 이런 데서 시간 보낼 필요가 없을 것이다. mingw기반의 msys나 cygwn도 마찬가지..) Visual Studio를 기반으로 프로그래밍 정보를 알아보자. 그리고 사실 최근에는 유닉스계에서만 활동하던 오프소스 개발가들이 윈도우도 많이 공략을 하고 있기 때문에 어느 환경에서건 컴파일되는 오픈소스들이 많다. ncurse처럼 유닉스계열과 윈도우계열의 터미널프로그램의 차이때문에 아직 포팅되기에 어려운 GNU소스들이 발목을 많이 잡긴 하지만..
우선 컴파일러가 있으면 프로그램을 짤 수 있는데 보통 프로그램을 짜는데 공용 라이브러리를 많이 사용한다. 프로그래밍에서 라이브러리랑 라이브러리에 있는 여러 루틴들을 호출해서 다른 프로그램에서도 사용할 수 있고 자주 쓰는 루틴들을 모아둔 것을 말한다. Visual Studio같은 윈도우용 프로그램의 경우 윈도우의 기본 OS의 함수들을 호출할 수 있는 라이브러리들이 우선 있어야 운영체제와 연결이 된다. 기본적인 함수는 C함수에서 지원이 되지만 시스템관련 함수들은 Widows SDK라고 해서 마이크로소프트사에서 주기적으로 업데이트가 가능하다. 기초적인 SDK는 이미 상용 버전에는 같이 포함되어 설치가 되니 상관없지만 무료버전의 경우 과거에는 따로 다운받아 설치해야 했다.
http://www.microsoft.com/downloads/en/default.aspx 같은 마이크로소프트의 다운로드센터에서 windows SDK 같은 단어로 검색하면 다운받아 설치할 수 있는데 새로운 윈도우 버전이 나올때 마다 새 버전의 OS를 지원하기 위해 업데이트 되곤 한다. 최근에는 윈도우7에서 돌아가는 프로그램을 만들 수 있게 SDK가 나와있다. 이런 것을 이용해서 구버전의 윈도우에서도 새 윈도우버전에서 돌아가는 프로그램을 만들 수 있는 것이다.
이 밖에도 윈도우시스템만의 특징인 directX의 SDK라던지 .NET Framework SDK라던지 윈도우의 기술관련 라이브러리들을 여기서 검색을 통해 찾아 설치할 수 있다. 여기서 윈도우개발에 관련된 다양한 소스와 툴들을 다운받을 수 있는 것이다.
기본적인 것이 갖추어 지면 이젠 어떤 라이브러리를 이용해서 프로그램을 만들고 컴파일하는가 하는 문제가 있다. 이건 요즘 프로그램이 OS에 무관한 호환성을 중시하기 때문이다. 하나의 프로그램을 만들때 단지 윈도우에서만 돌아가는 것과 비교해서 윈도우뿐아니라 리눅스나 맥에서도 돌아간다면 판매를 위한 것이건 무료사용을 위한 것이건 쓸 수 있는 범위자체가 달라지게 된다.
오픈 소스계에서 특히 이런 공용 라이브러리개발이 활기차다. 그래서 GPL라이센스를 가진 라이브러리들이 리눅스뿐 아니라 윈도우에서도 많이 오픈소스에선 사용된다.
예를 들면 비쥬얼스튜디오로 처음 프로젝트를 만들때 atl이나 mfc라이브러리를 쓸것인가 결정할 수 있는데 이런 라이브러리는 윈도우 전용 라이브러리이기 때문에 이런 것을 사용해서 프로그램을 짜게 되면 윈도우에서만 사용이 되게 된다. 그래서 윈도우전용이 아니면 대부분의 오픈소스프로젝트의 소스들을 보면 이런 라이브러리는 잘 사용을 하지 않는다.
최근의 대부분의 오픈소스 프로그램들이 주로 쓰는 여러 OS에서 사용되는 공용 라이브러리는 다음과 같은 것이 있다.
라이브러리마다 LGPL라이센스가 많긴 하지만 나름대로의 라이센스를 가진 것도 많으니 상용 프로젝트에 사용시는 라이센스를 확인해 보는 것이 좋다. LGPL라이센스의 경우는 나 같이 연구나 취미 그리고 배움을 위해 프로그래밍을 위한 사람들에게 적합한 라이브러리들이고 상용으로 쓸 경우는 LGPL라이센스의 라이브러리를 쓸 경우 라이브러리자체에 대한 변경만 없이 그냥 불러 쓰는 경우는 어떤 LGPL라이브러리를 썼는지 프로그램 라이센스 표시하는 데서 표시만 해주면 문제가 없을 것이다. 즉 All Right Reserved 이런식으로 쓰면 안되고 LGPL라이센스 사용부분은 표시를 해주어야 한다. 변경이 있으면 LGLP라이센스에 따라 변경된 부분의 소스를 공개해야 한다. 대부분 라이브러리는 그냥 호출해서 쓰니 상용에서 이런 라이브러리를 쓴다고 문제가 되는 경우는 드물것 같다. 실제로 LGPL라이브러리를 사용하는 상용프로그램의 수도 엄청나게 많다. GPL이 무료라고 소송주체가 없을거라 생각하면 오산이다. GPL3에 와서는 저작권을 어기면 처벌하는 것이 강화되었다. 그리고 내가 알기로 GPL이 깔아논 오픈소스의 기반이 워낙 넓어 기업형 개발회사가 아닌 이상은 이런 자잘한거 다 개발할 수 없기 때문에 개인의 경우는 이런 소스를 쓸 수 밖에 없다. 컴파일하면서 동적링크대신 정적링크로 은근슬쩍 감추어 놓은 상용 프로그램도 있을 수 있겠지만 이런거 IDA같은 디스어셈블러로 FLAIR을 이용한 라이브러리 분석해 보면 다 걸린다. 물론 또 안 걸리게 숨기는 방법도 없는건 아니지만 그런 이야긴 해커레벨로 넘어가니 여기선 넘어간다. GPL라이센스와 LGPL라이센스는 또 차이가 있다. 상용개발이 목표면 GPL라이센스는 피해야한다. LGPL정도는 괜찮지만 MIT나 BSD라이센스면 좋다. 반면에 계속해서 오픈소스로 남고싶은 프로젝트라면 GPL이 가장 좋다. 예를 들면 오래된 컴퓨터들의 에뮬레이터 프로그램같은건 상용이 된다면 너무 서운할 것이다. 이런건 GPL을 쓰면 해결된다. 라이센스문제는 나중에 상용으로 프로그램을 개발할 때나 신경써야 되니 여기선 넘어간다. 하지만 될수록이면 너무 빡빡한 라이센스를 가진 라이브러리는 쓰지 않는게 좋다.
zlib http://www.zlib.net/ - 이 라이브러리는 거의 필수지만 워낙 필수다 보니 여기저기 다른 패키지에 덤으로 들어있는 경우가 더 많다. 비쥬얼스튜디오 2005 이상에선 컴파일할때 contrib디렉토리에 있는 비쥬얼스튜디오 용 프로젝트를 쓰면 다른 프로그램 컴파일할때 호환성이 떨어지고 project디렉토리에 있는 vs6용 프로젝트를 컨버트해서 컴파일해야 된다. 둘이 생성하는 라이브러리이름이 다른데 다른 모든 프로그램이 vs6용을 쓰는게 일종의 스탠다드가 되버렸기 때문에 그렇다. 어셈블리어를 쓰는 빌드는 어셈블러가 vs6용으로 짜놓아서 vs6가 있어야 제대로 어셈블이 된다. 이 어셈블러만은 vs6가 없어도 vs6용 서비스팩에서 간단히 추출해 낼 수도 있다. 수치프로세서나 SSE나 3DNOW등을 지원하는 어셈블러는 서비스팩6가 아니라 프로세서팩에 든 어셈블러를 사용해야 된다.
http://download.microsoft.com/download/vb60ent/update/6/w9x2kxp/en-us/vcpp5.exe
비주얼 스튜디오 6가 안 깔려있는 사람은 이걸 설치하면 안되고 압축을 풀어 ml.exe ml.err만 (다른 파일을 쓰는지는 모르겠다) 어디 디렉토리에 저장해 두고 비쥬얼스튜디오 2005나 2008로 컴파일이 안되는걸 이걸로 컴파일하도록 하면 된다.
libpng http://www.libpng.org/pub/png/libpng.html - 이 라이브러리는 그림이나 멀티미디어관련 프로그램에선 거의 필수로 들어가는 라이브러리이다. PNG형식을 읽고 쓸려면 이 라이브러리가 필요하다. 멀티미디어 라이브러리중 그림 형식과 관련된 기본라이브러리가 있다면 바로 PNG, JPEG 그리고 TIFF형식과 관련된 라이브러리쯤 되고 좀더 고급프로그램에선 EXR형식까지 많이 쓰인다. EXR은 HDR형식을 대체하는 오픈소스형식이라고 이해하면 된다. 이 라이브러리는 컴파일할때 zlib를 같이 컴파일하기 때문에 zlib와 libpng를 설치하고 이것만 컴파일하면 zlib도 같이 컴파일된다. build의 종류도 그래서 zlib랑 같이 맞추어져 있다.
libjpeg http://www.ijg.org/ - 최근 버전7이 되었지만 그 동안 버전6의 라이브러리가 많이 사용되었다. 이 라이브러리는 오리지날이 공개된 이후 자잘한 패치업데이트가 여러 다른 사용자들에 의해 많이 나왔는데 호환성을 생각한다면 오리지날 그대로 쓰던지 아니면 패치된 라이브러리는 혼자쓰도록 정적링크를 시키던지 하는게 좋다. 여기저기 다양한 jpeg6라이브러리들이 있을수 있기 때문에.. 버전 7은 최근에 나와서 그런 문제는 아직 없는 것같다. 원래는 utah raster toolkit (urt)이라는 라이브러리의 기능을 옵션으로 쓸 수 있게 해 놓았지만 이 라이브러리가 윈도우에선 소스 그대로는 컴파일되지 않기 때문에 (파이프라던지 mmap이라던지 유닉스 전용 콜 기능을 좀 많이 사용하는 라이브러리이다) 윈도우판에선 urt랑 같이 링크된 라이브러리는 없다. 개인적으로 패치해서 쓸 수는 있지만 역시 호환성을 생각하면 urt를 무시해야 된다. visual c용 프로젝트 파일은 원래 버전 6에는 없었다. 이번 7버전에는 visual studio 2008용 프로젝트가 첨가되었다.. 그냥 프로젝트 그대로 배포하면 될것을 파일이름을 다 바꾸어 놓아서 다시 또 원래대로 고쳐서 써야 한다. 또 비쥬얼 스튜디오 2005용 프로젝트는 없다. 따라서 내가 만든 2005용 프로젝트를 첨부하니 컴파일에 필요한 해더파일들 이름만 제대로 바꾸어 주고 컴파일하면 된다.
libtiff http://www.libtiff.org/ 혹은 ftp://ftp.remotesensing.org/pub/libtiff
앞의 공식버전보다는 뒤에 ftp사이트에서 개발버전이지만 알파나 베타버전 빼고 최신버전을 받아 쓰는게 좋다. 이 라이브러리도 makefile.vc의 nmake용 빌드파일밖에는 제공하지 않는다. tif_config.h만 tif_config.vc.h에서 복사해서 만들어 주고 역시 첨부된 2005용 프로젝트를 사용해도 된다. tiff소스가 설치된 디렉토리에 풀어서 쓰면 된다.
테스트프로그램들은 아직 프로젝트에 첨가시키지 않았다.. 이 라이프러리는 tif_config.h만드는것 빼고는 그냥 makefile.vc에 있는 리스트만 옮겨주면 되니 프로젝트만들기가 쉽다.
bzip2 http://www.bzip.org/downloads.html zlib와 마찬가지로 압축관련 라이브러리이다. zlib보다는 많이 쓰이진 않지만 리눅스에선 gz압축보다 압축효율이 좋기 때문에 많이 쓰인다. 역시 비쥬얼스튜디오용 프로젝트파일은 없고 makefile.msc라는 nmake용 파일을 제공한다. 또 비쥬얼스튜디오 5용 dsp파일이 들어있어 그걸 이용해 컨버젼해서 쓸 수도 있다. 컨버젼한 프로젝트파일을 첨가한다.
freetype2 http://www.freetype.org/ or http://sourceforge.net/projects/freetype/files/
윈도우와 리눅스같은 유닉스시스템 모두에서 돌아가는 프로그램을 작성할 때 문제가 되는 것들이 많지만 그 중 하나가 폰트시스템의 호환성이다. 윈도우는 트루타이프나 오픈타이프 폰트를 쓰는데 반해서 유닉스에서 많이 쓰는 X윈도우 시스템은 보통 postscript font계열의 font나 bdf같은 bitmap font를 쓴다. 그래서 둘이 쓰는 font system과 무관하게 font관련 함수를 제공하는 공용 함수를 제공하는 라이브러리를 이용해 이런 비호환성을 극복하는데 freetype2는 원래는 윈도우의 truetype 폰트를 리눅스계에서 사용할 수 있게 하는 목적에서 출발했지만 요즘은 보다 다양한 폰트형식을 지원하는 범용라이브러리가 되었다. 보통 이 라이브러리를 유저가 직접 사용한다기 보단 보다 유저가 사용하는 GUI라이브러리들이 보통 이 라이브러리를 이용해서 다양한 폰트를 지원하게 된다. 즉 GUI라이브러리를 컴파일하기 위해선 필수는 아니지만 이 라이브러리를 이용하도록 옵션을 정하면 보다 다양한 폰트이용이 가능하다. 일부 라이브러리는 이 라이브러리를 필수로 요구하기도 한다. 최근 빌드에선 비쥬얼 스튜디오용 프로젝트파일이 첨가되어 있어 그냥 소스받아서 컴파일하면 된다.
openexr http://www.openexr.com/ 최근 3D나 2D의 그래픽시장에서 가장 최신 형식으로 사용되는 파일형식이 HDRi같은 형식이다. 과거 gif에서 시작해서 jpeg같은 그래픽데이타를 표현하기 위한 다양한 형식들이 있지만 보통 16비트형식에 고정된 밝기데이타를 지닌 이런 파일들과 비교해서 HDRi는 32비트의 도트 데이타를 지니고 보다 넓은 밝기범위를 표현할 수 있게 사용자가 다이나믹하게 gamma값을 지정할 수 있어 단순히 그림데이타를 저장한 것이 아닌 물리적으로 보다 리얼리티에 가까운 자연화면의 모습을 저장하기 위해 개발되었다.
자세한 것은 http://en.wikipedia.org/wiki/High_dynamic_range_imaging 을 참조하기 바란다.
원래 HDR형식은 radiance http://www.radiance-online.org/ 라는 3d 렌더링 프로그램이 기본의 그래픽파일형식이 아닌 보다 발달된 파일형식으로 렌더링결과를 저장하기 위해 사용하던 그래픽 형식이었다.
OpenEXR형식은 HDRi형식이 보통 상용툴기반의 형식인것에 반해 오픈소스기반의 개발툴을 제공하고 오픈스탠다드로 HDR을 급속하게 대체하기 시작했는데 채널당 16비트 도합 48비트나 60비트의 도트해상도를 지원한다. 표현방식도 정수형 표현이 아니라 실수를 사용한다. 최근 1.6.1버전의 라이브러리가 나왔는데 아직도 1.4.0a버전의 라이브러리를 쓰는 프로그램도 많다. 이 라이브러리는 3D관련 프로그램이 아니면 사실 많이 쓰이진 않는다..
다음으로 GUI관련 라이브러리를 좀 살펴보자.
http://en.wikipedia.org/wiki/List_of_widget_toolkits 에 보면 어떤 GUI라이브러리들이 주로 많이 사용되는지 나와있다. 해당 사이트를 찾아가면 다운도 받을 수 있다.
FLTK, FOX, GTK+,Qt,WxWidget 정도가 호환성이 좋은 라이브러리로 자주 듣는 라이브러리이름이 될것이다. 게임관련 프로그램에선 SDL (http://www.libsdl.org/) 같은 라이브러리도 많이 쓰인다.
리눅스에선 C기반의 gtk+와 gnome 라이브러리가 X말고 윈도우에 비해 주목할 만한 GUI가 없던 유닉스계에 거의 히트작이라고 할 수 있지만 이 라이브러리를 만들기 위해 들어가는 support라이브러리들이 많다 보니 윈도우에서 쓰긴 좀 상당히 까다로운 편이다. 원래가 리눅스의 개발환경에 적합하게 툴들이 많다 보니.. 사실 리눅스계에선 단순히 GUI라이브러리를 볼 것이 아니라 이런 라이브러리는 윈도우매니저로 통하게 되는데 Enlightenment만큼 Visual을 염두에 두고 개발된 툴은 없었던 것 같다. gtk+도 사실 원래 이런 라이브러리를 위해 개발된 것이 아니라 gimp같은 툴을 개발하기 위해 부가적으로 개발된 라이브러리이다. 아직은 호환성은 떨어지지만 Enlightenment에 관련된 라이브러리도 이런 새로운 바람을 불어 올지도 모르는 기대작이 되는 셈이다. http://www.enlightenment.org/
다음으로 라이브러리는 아니지만 각종 프로그램관련 소스를 다운받을 때 때로 필요한 svn, cvs같은 프로그램의 버전을 관리해 주는 프로그램을 살펴보자. 보통 소스를 배포할 때 새 버전이 나올때 마다 압축해서 배포본을 만들어 배포를 하지만 개발중인 프로그램의 경우라던지 이런 정식 배포본이 나오길 기다리기가 싫은 사람은 미리 개발본을 받아보길 원하는 경우가 있다. 개발본은 보통 오래된 cvs라던지 요즘 많이 쓰이는 svn같은 revision control system을 통해 관리되고 그걸 다운 받는 사람은 그것을 다운받을 수 있는 클라이언트 프로그램을 이용해서 다운을 받거나 개발에 직접 관여하고 싶은 경우는 아이디를 등록해서 개발에 참여할 수도 있지만 보통 그냥 다운을 위해서도 이런 클라이언트를 받아 설치해야 된다. 보통은 이런 프로그램들이 유닉스용이라 윈도우용은 좋은 클라이언트가 별로 없어서 cygwin에서 다운받곤 했는데 최근에 사용이 훨씬 편안한 클라이언트들이 개발이 되었다.
cvs http://www.tortoisecvs.org/
svn http://tortoisesvn.net/about
위 사이트에서 해당 툴을 다운받아 쓰면 된다. cvs는 서버를 설치할 수 있는데 일반 사용자의 경우 다운을 위한 것이고 서버를 설치하면 백그라운드 서비스가 하나 더 돌아가기 때문에 그냥 클라이언트만 설치해도 된다.
cvs 하고 svn말고 hg라고 Mercurial 이라는 revision control system을 쓰는 경우도 있는데
hg http://bitbucket.org/tortoisehg/stable/wiki/Home
에서 클라이언트를 다운받을 수 있다.
자 그럼 마지막으로 프로그램을 컴파일할 준비가 되었으면 어떤 사이트에서 원하는 소스들을 얻을 수 있나보자.
물론 고글같은데서 검색을 할 수 있지만 오픈소스만을 전문적으로 다루는 사이트는 몇개 없으니 그런 사이트를 보면 다음과 같다.
http://sourceforge.net/ 아주 질 좋은 오픈소스 개발 커뮤니티이다. 고글이 비슷한 서비스를 하고 있지만 고글 서비스가 있기 전부터 있던 관록이 있는 사이트다. 여기에서 배출된 유명 소프트들이 많고 상용프로그램들이 오픈소스로 전향할 때 주로 소스공개를 위해 찾는 사이트가 바로 여기다. 그렇다 이 사이트를 소개하기 위해 수정을 할 정도로 주목할 사이트다. 나머진 고글 검색하면 된다..
다음에는 전문 분야별로 내가 관심을 가지는 분야의 연구용 소스나 소프트웨어를 기회가 되면 소개하겠다.