make 로 실행하는 명령어는 서로 다른 셸에서 실행 되는 것처럼 동작한다. 따라서...
- 수행되는 작업의 순서가 파일 간의 관계 에만 주로 영향을 받는 경우
make기술 파일을 사용하여 모든 것을 제어할 수 있으나 - 변수 조작 을 여러 번 해야 하거나 실행 순서를 변경 해야 하는 경우 (
if문이나 내부exit명령어 등) 에는 셸 스크립트를 사용 하는 것이 더 용이하다.
1. 파일 이름의 패턴 매칭(Pattern Matching)
make 에서는 셸에서 사용되는 패턴 매칭 문자(Pattern Matching; *, ?, []) 를 명령행 뿐만 아니라 종속 항목에서도 사용할 수 있다.
그러나 make 에서 여러 개의 필요 항목을 지정하는 좀 더 안정적인 방법을 제공하기 때문에 (책에는 소개되어 있지 않지만 $(wildcard) 가 있다), 패턴 매칭 문자로 파일을 치환하는 방법이 자주 사용되지는 않는다. 일반적으로 기술 파일에서는 모든 필요 항목을 명시적으로 지정한다.
2. 각각의 명령행
make 는 각각의 명령행을 해당 셸에서 각각 실행 되는 것처럼 처리한다. 따라서, 아래의 명령들은 make 에서 독자가 예상하는 것처럼 동작하지 않는다:
clean:
cd output
rm *그러나 아래의 경우에는 두 개의 명령어가 하나의 명령행에 있기 때문에 문제가 없다. (역슬래시 또한 사실상 명령을 하나의 행으로 묶어주기 때문에 이 또한 가능)
cd output; rm *
# 혹은 역슬래시를 활용해서
cd output; \
rm * cd 와 exit 과 같이 내장된 명령어들은 기술파일에서 매우 제한된 결과를 만들어 낸다. 따라서 독자는 exit 를 사용하여 작성 중간에 make 를 자연스럽게 중단할 수 없다. make 가 중단되는 시점은 다음과 같다:
make의 빌드가 끝났을 때- 각각의 명령이 오류는 만들었을 때
- 프로세스를 강제 종료 시켰을 때
독자는 하나의 행에서만 셸 변수를 설정하고 사용할 수 있으며 셸 변수의 참조는 $$ 으로 한다.
for i in tune_file tempfile: do \
cat $$i >> logfile; \
rm $$i; \
done 또한 두 개의 달러 기호는 make 에 의해 생성된 셸에서 사용되는 변수들에만 적용된다. 두 개의 달러 기호를 사용하는 것이 make 를 실행시키기 전에 로그인 셸에서 설정하는 환경 변수들에는 불필요하다. 2 장에서 소개했듯이 make 는 환경 변수를 읽어들여 이들을 매크로처럼 처리하기 때문이다.
3. 오류와 종료
명령어와 오류를 발생하는 경우, 다시 말해 0 이 아닌 종료 상태인 경우 make 는 종료하게 된다. 그러나 오류를 예상하고 처리할 수 있다면, make 는 최소한 파일을 보호할 수 있으며, 필요에 따라 작업을 계속할 수 있도록 일부 옵션을 제공한다:
- 명령 앞에 하이픈(-)을 두게 되면
make는 오류가 발생하더라도 작업은 계숙 수행한다. .IGNORE타깃의 필요 항목으로 등록된 파일에 대한 명령의 경우, 오류가 발생하더라도 작업을 계속 수행한다.make를-i옵션으로 실행시킨 경우, 오류의 상관없이 실행 된다.-k옵션을 주게 되면 한 번의 여러 타깃을 독립적으로 만들 때 하나의 타깃에서 오류가 발생하더라도 다른 타깃의 빌드는 멈추기 않게 작업을 수행한다.
4. 다른 셸에서의 동작
여러 셸에서도 사용이 가능한, 포팅이 가능한 기술 파일을 작성하려면, 독자가 현재 사용하로 있는 make 나 로그인 셸의 특수 기능을 사용해서는 안된다. 본 셸에 따라 명령어를 작성하도록, 아래의 매크로 정의를 모든 기술 파일의 제일 첫 부분에 두어 본 셸을 사용하게 만드는 것이 바람직하다.
기술 파일에서 표준이 아닌 셸을 사용하는 경우 약간의 위험한 점이 있다. 사람들이 서로 다른 셸을 사용할 가능성이 있기 때문이다. 따라서 제일 좋은 방법은...
- 셸 자체를 사용하지 않는 것이 바람직하며
- 사용해야 한다면 이를 별도의 파일로 분리하여 기술 파일에서 이를 실행하는 것이 좋다.
5. 경로명과 보안
상대적인 경로를 사용해야 하는지 절대적인 경로를 사용해야 하는지에 대해 사용자들은 다양한 의견을 가지고 있다.
- 절대 경로의 사용
유닉스 시스템의 안전이라는 견지에서 이를 살펴보면, 자동화된 프로시저들에 대해 탐색 경로는 주의깊게 설정해야 한다. 다시 말하면, 독자는 표준 디렉토리가 아닌 곳에 있는 같은 이름의 명령을 실행시킬 수 있으므로, cat 과 같이 간단한 명령어도 make 기술 파일이나, 셸 스크립트, 또른 crontab 항목에서 그냥 사용하는 것은 좋지 않다.
단순한 실수 뿐 아니라 크래커에게 악용되는 일을 막기 위해, 전체 파일 경로인 /bin/cat 을 지정하거나, 환경 변수 PATH 를 명시적으로 설정해야 한다.
- 상대 경로의 사용
코드에 경로를 직접 표시하는 방법은 새로운 시스템에 대한 구성이나 작성 절차가 필요할 경우 매우 불리하다. 네트워크 내부 또는 외부의 시스템에서, 여러 디렉토리를 번갈아 마운트하며 다양한 개발 환경을 갖는 경우 탐색 경로는 매우 쉽게 변경될 수 있다.
많은 개발팀들은 C 코드에서 상수를 하드 코딩(hard-coding)해서는 안되는 것처럼, 경로를 하드 코딩해서는 안 된다. 따라서, 이 경우 환경 변수를 사용하여 디렉토리의 이름을 지정하고, 셸 스크립트와 기술 파일들에서 사용되는 탐색 경로를 지정한다.
Reference
[Book] The GNU Make Reference Manual Version 4.2 (Richard M. Stallman, Roland McGrath, Paul D. Smith), A GNU Manual
[Book] Make: 유닉스, 리눅스 필수 유틸리티 (앤드류 오람, 스티브 탈보트 저; 이석주 역)
