gurugio의 블로그

도배해서 죄송합니다. 합쳐서 올리면 너무 길것 같아서 나눠서 올립니다.
관심좀..굽신굽신 =)
------------------------

2단계에서는 빌드와 관련된 모든 정보를 하나의 파일에 모아서 처리해보았습니다. 그런데 아직도 하나가 각 Makefile에 남아있습니다. 바로 빌드 명령입니다. 실제로 컴파일러, 링커를 호출하는 빌드 명령이 각 Makefile에 남아있고, 누군가가 실수로, 혹은 잘 몰라서, 아니면 잠깐 급해서라도 이 명령을 손대면 전체 제품의 빌드에 문제가 생길 수 있습니다. 이번에는 아예 빌드 명령까지 분리해서 각 서브 디렉토리의 Makefile에는 이 디렉토리의 최종 산출물에 대한 정보만 저장되도록 만들어보겠습니다.

빌드 순서를 생각해보면 configure는 프로젝트를 빌드할 플랫폼에 대한 정보를 얻습니다. 그리고 make가 실행되면서 make에 지정된 옵션에 따라 빌드가 시작됩니다. 따라서 실질적으로 빌드 프로세스를 조정할 수 있는 것은 make의 옵션입니다. 따라서 make의 옵션을 인식해서 옵션에 맞게 빌드를 진행할 수 있도록 Makefile을 작성해보겠습니다.

먼저 아주 단순한 Makefile을 작성해보겠습니다. GNU make가 제공하는 매크로는 사용하지 않고, 개발자가 모든 명령을 직접 Makefile에 써주는 형태를 보여드리겠습니다.

가장 먼저 만들 것은 소스 트리의 가장 상위 Makefile입니다. 지금부터 소스에서 가장 상위 디렉토리가 현재 디렉토리라고 가정하겠습니다. 따라서 가장 상위의 Makefile은 ./Makefile이라고 표시됩니다. 다음은 ./Makefile의 내용입니다.

# config.mk is generated by configure
include config.mk

all:
make -C src
make -C test

clean:
make -C src clean
make -C test clean

빌드 과정을 준비하기 위해 빌드 대상이 될 소스를 몇개 만들겠습니다. 소스가 저장되는 디렉토리는 src와 test가 있습니다. src 디렉토리는 CA라이브러리에 들어갈 소스들이 저장됩니다. 그리고 test 디렉토리는 CA라이브러리의 각 API를 테스트할 유닛 테스트 소스들이 저장됩니다.

현재는 configure에서 생성해준 플랫폼 정보가 있으므로 이 정보를 알려주는 API를 만들어보겠습니다. 그리고 이 정보를 화면에 출력하는 유닛 테스트를 만들어보겠습니다. 엄밀히 말하면 유닛테스트 프로그램이 화면에 데이터를 출력하고 끝난다면 테스트로서 의미가 없지만 실행 파일을 빌드하는 예제를 만들기 위해서 그렇게 만들어보겠습니다.

다음은 src/sys_info.c 입니다.

/*********************************************************************
* $Id$
*********************************************************************/

#include
#include

점점 쓸데없이 길어집니다.. 문맥도 혼란스럽고 뒤죽박죽이 되갑니다..
관심좀 주세요 :-(

CPK 2.2 configure.in, config.mk.in, platform.h.in 작성
configure의 가장 큰 목적은 플랫폼 환경을 분석해서 프로그램이 플랫폼 환경에 상관없이 일정하게 동작하도록 해주는 것입니다. 사용자가 프로그램을 빌드하고자하는 환경은 아주 다양합니다. 운영체제가 32비트이거나 64비트일 수 있고, 헤더 파일의 위치가 다르거나, 운영체제 자체가 다를 수 있습니다. 또 프로그램을 빌드하기 위해서는 libabc.so 라는 라이브러리가 있어야하고, abc.h라는 헤더가 있어야 하는데 이런 다양한 환경을 찾아내서 지금 빌드할 플랫폼이 어떤 환경인지를 찾아내는 것이 configure의 임무입니다.

제품을 개발하는 단계를 아주 단순화해보면 요구사항분석, 설계, 개발, 테스트(, 수금??)으로 분류할 수 있습니다. 개발 단계만 생각해보면 개발 단계에서 가장 첫번째 단계가 빌드 환경을 작성하는 것입니다. 빌드라는 것은 간단하게 말하자면 여러 디렉토리에 여러개로 흩어져있는 소스들을 컴파일하고, 외부 라이브러리를 링크해서 최종 제품을 생산하는 일이라고 생각할 수 있습니다. 빌드 환경이 꾸며진 다음부터는 차례대로 소스를 작성해나가면서 수시로 빌드와 테스트를 진행하게 됩니다.

1.4 emacs 활용 연습
소스 등록, 소스 작성, 빌드, 빌드에러확인, gdb실행, 프로그램실행,소스 커밋

emacs를 가지고 간단한 소스를 작성해서 subversion에 등록하고, 소스 작성, 컴파일, 컴파일 에러 수정, gdb 디버깅, 프로그램 실행, 소스 커밋을 하는 연습을 해보겠습니다.

먼저 subversion 계정을 만드시기 바랍니다. 개인 머신에 서버를 만드시거나, 구글 코드 등의 서비스 사이트에 가입하시는 것도 좋습니다. 구글 코드가 초기에는 매우 느리고 불편했는데 최근에는 속도도 빠르고 안정적이어서 즐겨 사용하고 있습니다.

일단 subversion 계정이 있다는 가정에서 시작하겠습니다. 미리 subversion에 커밋된 study라는 디렉토리를 가지고 있다고 가정하겠습니다. 최초로 디렉토리를 등록하는 방법은 사용하시는 subversion 서비스에 따라 다르므로 해당 사이트에 문의를 하시기 바랍니다.

CPK 1.3 emacs 활용
svn-status(update, diff, revert 등등), gtags, gdb, tramp, 컴파일 및 에러 이동, eshell,

C프로그래밍에 필요한 emacs 기능들을 몇가지 소개하겠습니다. emacs는 사실 편집기라고 생각하기 어색할 정도로 기능이 많습니다. 하드웨어 부팅만 안할뿐이지 운영체제가 하는 일을 거의 다 할 수 있습니다. 웹 브라우징도 되고 스케줄 관리, 통합 개발 툴, 터미널, e-메일, ftp, telnet, ssh 등등 뭐가 지원 안되는지를 알기 힘듭니다. GUI기반 통합개발툴처럼 개발 환경을 꾸밀수도 있습니다. 제가 익숙하지 않아서 못쓸 뿐이지 개발에 필요한 기능은 모두 있다고 생각하면 됩니다. GUI 개발툴처럼 버전이 달라질때마다 동작이 달라지거나, 추가 비용이 들어가는 일도 없습니다. 한번 익숙해지면 운영체제에 상관없이 어디에서나 똑같은 개발 환경을 무료로 꾸밀 수 있습니다.

이번 장에서는 emacs 설정에 대해 간략하게 알아보겠습니다. emacs의 설정파일은 사용자의 홈 디렉토리에 .emacs 파일로 저장됩니다. emacs는 그자체가 LISP언어의 인터프리터이기 때문에 일반적인 프로그램과는 설정 방법이 조금 다릅니다.

1. 설정 파일을 Emacs Lisp이라는 언어로 작성해야 합니다.
2. 설정 파일을 작성하는 것 자체가 프로그래밍입니다.
3. 설정 자체가 프로그래밍이므로 무한한 자유도를 가집니다. 내가 어떠한 기능이라도 프로그래밍만 하면 추가할 수 있습니다.
4. 하지만 잘 알지 못한다면 어떻게 시작해야할지 조차 감을 잡기 어렵습니다.

어떤 설정관련 변수들이 있는지, 어떤 함수들이 있는지 등은 emacs 메뉴얼을 보면서 알아내야합니다. 하지만 저는 여기저기에서 많은 분들의 설정 파일을 보면서 조금씩 이해한다음 저에게 필요할만한 기능들을 모았습니다. 어느정도 사용하다보니 LISP언어를 몰라도 간단한 설정은 직접 할 수 있게 되었습니다.

코딩에 가장 필요한 몇가지 설정에 대해 먼저 소개하겠습니다.