다음 이전 차례

3. 바람직한 개발의 관례

이에 관한 내용들 중 대부분은 리눅스뿐만 아니라 다른 유닉스에서도 이식가능하도록 프로그램을 작성하는 것과 관련이 있다. 다른 유닉스에 이식가능하게 하는 것은 단지 전문적이고 해커의 고상한 가치의 형태가 아니라, 리눅스 스스로 미래의 변화에 대비하는 것에 가치가 있다.

마지막으로, 다른 사람이 당신의 코드를 리눅스 시스템이 아닌 곳에서 사용하려고 한다면, 이식성은 당신이 받을 성가시고 난처한 메일들을 최소한으로 줄일 수 있을 것이다.

3.1 ANSI C 나 이식가능한 스크립 언어로 작성하라

이식성과 안전성을 위해 ANSI C 나 이식가능한 스크립 언어로 작성해야 한다. 왜냐하면 다른 플랫폼에서의 실행을 위해서이다.

스크립 언어로 적당한 것은 Python, Perl, Tcl, 그리고 Emacs Lisp등이다. 간단한 옛날 shell 은 적당하지 않다. 구별하기 힘든 특이한 표현법과 shell aliases와 같은 사용자 설정의 혼란에 영향을 받는 shell 환경 때문에 실행에 많은 어려움이 있다.

자바는 이식가능한 언어라고 믿어져지지만 리눅스에서의 실행은 아직까지 서툴고 부족하다. 자바의 성장으로 날로 인기가 높아지지만 자바는 여전히 힘든 선택이다.

3.2 C가 이식가능하도록 관례를 따라라

만약 C로 프로그램을 작성한다면 완전한 ANSI 규정(다른 모듈과의 불일치를 알 수 있도록 도와주는 함수 프로타입을 포함한)을 따른 것을 사용해도 괜찮다. 구식의 K&R 컴파일러가 고전적이다.

그 반면, GCC-specific 규정(`-pipe' 옵션과 같은)또는 nested 함수가 이식가능할 것이라고 추측하지마라. 이것들은 갑자기 나타나서 리눅스 시스템, GCC 시스템이 아닌 곳에 옮기려는 사람이 당신을 괴롭히게 만들 것이다.

3.3 autoconf/automake/autoheader 를 사용하라

C를 사용해서 프로그램을 작성했다면 다른 곳에 이식할 수 있도록 조정하고 시스템 설정에 적응하고 또 makefile을 고치기 위해서 autoconf/automake/ autoheader을 사용해라. 요즘 소스를 프로그램을 사용하고(build) 싶어하는 사람들은 "configure; make"라고 치면 깨끗하게 프로그램이 만들어지기를 바란다 -- 그리고 그렇게 해야 한다.

3.4 공개 발표 전에 코드가 온전한지 검사하라

C로 프로그램을 작성하였다면 `-Wall' 옵션을 사용하여 테스트-컴파일러를 해보고 공개하기 전에 최소한 한번이라도 오류를 제거해야 한다. 이렇게 하면 많은 엄청난 오류들을 발견할 수 있을 것이다. 철저하게 `-pedantic' 옵션을 사용해 컴파일러 하는 것도 좋은 방법이다.

Perl을 사용하였다면 공개 전에 perl -c, perl -w, 그리고 perl -T를 사용해서 코드를 검사해야 한다. (Perl에 관한 문서를 참고하라)


다음 이전 차례