2단계에서는 빌드와 관련된 모든 정보를 하나의 파일에 모아서 처리해보았습니다. 그런데 아직도 하나가 각 Makefile에 남아있습니다. 바로 빌드 명령입니다. 실제로 컴파일러, 링커를 호출하는 빌드 명령이 각 Makefile에 남아있고, 누군가가 실수로, 혹은 잘 몰라서, 아니면 잠깐 급해서라도 이 명령을 손대면 전체 제품의 빌드에 문제가 생길 수 있습니다. 이번에는 아예 빌드 명령까지 분리해서 각 서브 디렉토리의 Makefile에는 이 디렉토리의 최종 산출물에 대한 정보만 저장되도록 만들어보겠습니다.
빌드 순서를 생각해보면 configure는 프로젝트를 빌드할 플랫폼에 대한 정보를 얻습니다. 그리고 make가 실행되면서 make에 지정된 옵션에 따라 빌드가 시작됩니다. 따라서 실질적으로 빌드 프로세스를 조정할 수 있는 것은 make의 옵션입니다. 따라서 make의 옵션을 인식해서 옵션에 맞게 빌드를 진행할 수 있도록 Makefile을 작성해보겠습니다.
빌드 과정을 준비하기 위해 빌드 대상이 될 소스를 몇개 만들겠습니다. 소스가 저장되는 디렉토리는 src와 test가 있습니다. src 디렉토리는 CA라이브러리에 들어갈 소스들이 저장됩니다. 그리고 test 디렉토리는 CA라이브러리의 각 API를 테스트할 유닛 테스트 소스들이 저장됩니다.
현재는 configure에서 생성해준 플랫폼 정보가 있으므로 이 정보를 알려주는 API를 만들어보겠습니다. 그리고 이 정보를 화면에 출력하는 유닛 테스트를 만들어보겠습니다. 엄밀히 말하면 유닛테스트 프로그램이 화면에 데이터를 출력하고 끝난다면 테스트로서 의미가 없지만 실행 파일을 빌드하는 예제를 만들기 위해서 그렇게 만들어보겠습니다.
8. 오브젝트 도출
이번 편을 쓰기 전에 제목을 무엇으로 해야 하나 약 1분간 깊은 고민을 했다. 제목을 정하기 위해 구글 검색을 할 정도였다. 이번 편에 작업하고자 하는 내용은 단순하고 명확하다. 지난 글에서 분석한 명사와 동사를 기준으로 데이터 베이스의 테이블과 코드 로직의 메소드, 코드 로직의 자료 구조등을 도출해 내는 작업이다. 나는 이것들을 통칭할 수 있는 용어로 "오브젝트"라는 용어를 직관적으로 떠올렸다. 하지만 바로 이어서 "엔티티"라는 용어가 치고 올라왔고 내 머릿속은 복잡해 졌다.
사용자가 가지고 있는 신체적 특성(예, 장애)는 두 말할 것도 없이 지식 수준, 연령 등 고려할 요소는 매우 많고 이 모든 사용자들을 만족할 만한 통일된 UI란 존재할 수 없다.
내가 요즘 인터페이스에 대한 생각을 다시 가지게 되는 것은 80이 넘으신 할머니에게 집에서 사용하지 않는 노트북에 우분투를 깔아서 드리면서 부터 이다.
소일거리가 별로 없으신 할머니께서 지루해 하시는 것 같아, 수도쿠 같은 게임이라도 즐기시라고 한 것인데, 생각보다는 적응을 잘 하셨다.
수도쿠보다는 마장이나 특히 kdiamond를 즐겨 하시지만...
80이 넘으신 문맹에 가까운 할머니께 우분투 데스크탑은 어떨까?
(문맹은 아니시지만, 글을 읽는 속도가 매우! 느리시다)
사실, 그냥 기본으로 우분투를 설치한 상태라면 사용하시기가 절대로 쉽지 않을 실 것이다.
그래서, 내가 한 것이 자동로그인, 스크린세이버 이후 암호입력제거, 키링에서 암호입력제거 등등
많은 보안 관련 루틴을 우회하게 하는 것이었다.
KLDP 블로그는 그다지 화려하지도, 많은 기능을 제공하지도 않지만 F/OSS, IT에 관련된 충실한 내용을 담고자 노력하는 분들이 함께 만들어 나가고 있습니다. 혹시라도 이곳에서 블로그를 운영하시고자 하는 분은 이곳으로 어떤 내용으로 운영하실지를 알려 주십시오. 확인 후 개설 여부를 결정하여 알려 드리도록 하겠습니다.
그누 이맥스 시작하기
