티스토리 뷰

1. 프로젝트 repositoryREADME-kor.md 파일 작성

제안서 내용 순서를 README 파일에 어울리게끔 재배치하였다.

https://github.com/YejinHwang-D/rm-execpt-files/blob/main/README-kor.md

 

GitHub - YejinHwang-D/rm-execpt-files: written in shell script

written in shell script. Contribute to YejinHwang-D/rm-execpt-files development by creating an account on GitHub.

github.com

<README-kor.md 캡처>

 

 

2. GNU 라이브러리 컴파일 문제 해결

A.     기존 컴파일 문제

/home/kmi0817 디렉터리에서 “git clone git://git.sv.gnu.org/coreutils”를 실행하였다. 이후 “cd coreutils” 실행하여 현재 워킹 디렉터리를 /home/kmi0817/coreutils로 변경하였다.

< 그림1: gcc rm.c -o rm>

rm.c 파일만 컴파일하기 위해 “gcc rm.c -o rm” 입력했지만, config.h 헤더 파일 include 문제 발생하였다.

< 그림2: make rm>

GNU coreutils가 생성한 make를 활용하여 “make rm” 입력했지만, 똑같은 문제가 발생하였다.

 

 

B.     해결 방법

1)    README 파일

사전조사 없이 곧바로 컴파일을 시도했던 터라, README 파일부터 읽어보았다. README 파일에는 git clone으로 GNU coreutils를 가져왔다면, README-hacking 확인하라는 안내가 있었다.

 

2)    README-hacking: ./bootstrap

Build 과정에 필요한, 다른 소스 패키지의 파일을 가져오거나 확인하기 위해서는 “./bootstrap”을 입력하라고 한다.

<그림3: ls on /home/kmi0817/coreutils>

그림3에서 알 수 있듯, bootstrap 위치는 현재 워킹 디렉토리 (/home/kmi0817/coreutils)이다. 따라서 곧 바로 “./bootstrap”을 입력하였다.

<그림4: ./bootstrap>

그러나 autoconf, automake, autopoint 등 다른 패키지가 발견되지 않는다는 에러가 출력되었다. 더불어 README-prereq에서 프로그램을 실행하는 데 필요한 전제조건을 만족하는 방법을 확인하라고 하였다.

 

3)    README-prereq: 필요한 도구 설치

bootstrap, configure 스크립트와 make를 사용하려면 위 도구들이 필요하다고 한다. 따라서 “sudo apt-get install <도구 이름>” 명령어로, 모든 도구를 설치하였다. 이때 각 도구 이름은 모두 소문자로 표기하며, 도구 이름에 띄어쓰기가 있는 XZ Utils의 경우 xz-utils를 입력하여야 했다.

위 첨부 파일은 autopointgperf 도구를 설치하는 화면을 일부 캡쳐한 사진이며, git, make처럼 README-prereq에 나열된 도구 중에는 이미 설치되어 있는 도구도 섞여 있었다.

도구 설치 명령어
sudo apt-get install autoconf
sudo apt-get install automake
sudo apt-get install autopoint
sudo apt-get install bison
sudo apt-get install gettext
sudo apt-get install git
sudo apt-get install gperf
sudo apt-get install gzip
sudo apt-get install help2man
sudo apt-get install m4
sudo apt-get install make
sudo apt-get install perl
sudo apt-get install tar
sudo apt-get install texinfo
sudo apt-get install wget
sudo apt-get install xz-utils

 

4)    ./bootstrap

필요한 도구를 모두 설치한 후 다시 한 번 /home/kmi0817/coreutils 위치에서 “./bootstrap”을 입력하였다. 에러가 뜨던 처음과는 다른 화면이 출력되었다.

<그림5: 필요 도구 설치 이후 ./bootstrap>

출력 내용은 대강 이러하였다.

하위 모듈 ‘gnulib’ (git://git.sv.gnu.org/gunlib.git)‘gnulib’이라는 경로에 등록되었다.
gnulib/home/kmi0817/coreutils/gnulib cloning 중이다.


po/ko.po… 등 많은 언어 update 및 많은 m4/…, po/… 파일 copy

dependency 처리

 

<그림6: ./bootstrap 실행 완료>

그림6“./bootstrap” 실행 완료 부분을 캡처한 것이다. 마지막 줄을 보면, ./bootstrap 실행이 완료되었으니 ./configure를 실행하라는 문장이 있다.

 

6)    ./configure

<그림7: ls after bootstrap on /home/kmi0817/coreutils>

그림7을 통해 configure 실행 파일의 위치가 /home/kmi0817/coreutils임을 알 수 있다. 그림3과 같은 디렉터리에서 ls 명령어를 실행하였는데, GNUmakefile, INSTALL, configure 등 새로운 파일이 몇 가지 추가되었다. 이는 ./bootstrap 명령어가 실행되면서 Build에 필요한 파일을 추가하였기 때문이다.

<그림8: ./configure>

configure 실행 파일을 실행하였다. C 컴파일러 작동 여부, makenested variable 지원 여부 등을 확인하고 있다.

 

6)    makemake check

REAME-hacking 파일을 다시 한 번 확인하였다. ./bootstrap./configure를 실행하였으니, 이제 1) make 2) make check 3) git diff를 진행할 차례이다.

< 그림9: make>
<그림10: make check>

make 이후 make check를 입력하였다. make check GUN coreutils를 테스트하는데, 테스트를 마치면 아래와 같은 테스트 요약본을 출력한다.

<그림11: make check의 summary>

마지막으로 모든 GNU 라이브러리가 정상적으로 로컬 디렉터리에서 build 되었는지 확인하기 위해 “git diff”를 입력하였다.

<그림12: git diff>

입력에 대한 출력이 없어야 Git master와 로컬 카피본의 차이가 없는 것이다. 그림12을 보면 git diff에 대한 출력이 없으므로 그동안의 모든 작업이 정상적으로 처리되었음을 알 수 있다. , 기존의 헤더 파일 include 관련 컴파일 문제가 해결된 것이다.

 

 

C.     GNU 명령어 테스트

<그림13: ls on /home/kmi0817/coreutils/src>

현재 워킹 디렉터리는 /home/kmi0817/coreutils/src이다. 그림13을 보면, src 디렉터리에는 build 이전부터 존재하던 c 언어 소스 파일뿐만 아니라 오브젝트 파일과 바이너리가 추가되었다. 따라서 해당 rm 바이너리가 일반 GNU 명령어 rm와 같은 기능을 수행하는지 테스트를 진행하였다.

테스트 환경은. /home/kmi0817/test 디렉터리에 3개의 파일이 존재하는 상황이다.

 

1)    Test Case: 파일 삭제

/home/kmi0817/test 디렉터리에서 test.txt 파일을 삭제하였다. 이번 Test Case에서는 rm 명령어의 옵션을 사용하지 않은 채 순수 rm 명령어 기능만 테스트하였다.

 

2)    Test Case: 디렉터리 삭제

/home/kmi0817 디렉터리에서 test 디렉터리를 삭제하였다. 이번에는 rm 명령어에, 강제 삭제 옵션인 -r와 삭제 여부 확인 옵션인 -i를 적용하였다. rm -ri [디렉터리명]은 입력한 디렉터리 진입 여부 및 해당 디렉터리 내 파일 삭제 여부를 확인한다.

 

2개의 Test Case를 통해 rm 바이너리가 기본 rm 명령어와 동일하게 동작함을 알 수 있었다. 다음주부터는 본격적인 옵션 개발을 시작할 계획이다.

728x90