영어프랑스어스페인어

Ad


온웍스 파비콘

makepp_rules - 클라우드에서의 온라인

Ubuntu Online, Fedora Online, Windows 온라인 에뮬레이터 또는 MAC OS 온라인 에뮬레이터를 통해 OnWorks 무료 호스팅 제공업체에서 makepp_rules를 실행하세요.

Ubuntu Online, Fedora Online, Windows 온라인 에뮬레이터 또는 MAC OS 온라인 에뮬레이터와 같은 여러 무료 온라인 워크스테이션 중 하나를 사용하여 OnWorks 무료 호스팅 제공업체에서 실행할 수 있는 makepp_rules 명령입니다.

프로그램:

이름


makepp_rules -- makepp에게 무언가를 빌드하도록 지시하는 방법

기술


?: &,
-,
@, B: :빌드_캐시,
:빌드_체크, D: :보내다, E: :환경, I: "무시_오류",
:포함하다, L: :마지막 기회, M: 메이크펄, N: "노에코", P: :파서,
"펄", S: :서명

규칙은 makepp에게 파일이나 파일 클래스를 빌드하는 방법을 알려주는 것입니다. Makepp은 다음을 지원합니다.
make의 다른 구현과 동일한 규칙 구문과 자체 추가 사항이 있습니다.

규칙에는 일반적인 형식이 있습니다.

target_expression : 종속성_표현 [ : 선택적 인수]
행위

대상 목록에는 자동 변수("$(foreach)" 제외)가 포함될 수 없습니다. 그만큼
종속성 목록에는 대상을 참조하는 자동 변수만 포함될 수 있습니다(예:
"$(출력)", "$(출력)" 또는 해당 동의어). 작업에는 자동이 포함될 수 있습니다.
변수.

makepp이 규칙을 실행해야 한다고 결정하면 규칙의 각 줄이 실행됩니다.
순차적으로 수행되며 XNUMX이 아닌 상태를 반환하는 경우 나머지는 실행되지 않습니다.
명령줄에서 "-k" 옵션을 지정하지 않으면 makepp가 오류와 함께 중단됩니다.)
각 작업은 한 줄로 이루어져야 합니다. 액션이 너무 길어서 편리하게 쓸 수 없는 경우
한 줄이면 여러 줄로 나누고 백슬래시를 넣어서
여러 줄을 하나로 결합해야 합니다.

다음 규칙과 액션을 구별하기 위해 액션을 더 들여쓰기해야 합니다.
대상과 종속성을 포함하는 줄보다. 다른 구현과는 달리
make, makepp는 들여쓰기 정도나 탭 문자 사용 여부에 크게 신경 쓰지 않습니다.
공백보다는. 기존 제조업체와의 하위 호환성을 유지하려면 규칙이 필요합니다.
makepp는 언제 작업이 종료되고 다음 규칙이 시작되는지 결정하는 데 사용하는 것은 다소 복잡합니다.

· 첫 번째 작업 줄은 대상이 포함된 줄보다 더 많이 들여쓰기되어야 합니다.

· 줄에 탭 문자 8개 또는 공백 XNUMX개 이상이 들여쓰기되어 있으면 들여쓰기된 것으로 간주됩니다.
액션 라인.

· 빈 줄이나 오른쪽 여백에 "#" 문자가 있는 주석 줄이 끝납니다.
규칙, 비어 있지 않은 다음 줄이 8칸 이상(또는 XNUMX칸 이상) 들여쓰기되지 않는 한
탭).

· 한 줄이 첫 번째 작업 줄보다 많이 들여쓰기되면
추가 조치 라인으로 간주됩니다.

몇 가지 특별 조치 항목이 있습니다:

& 이 기호 뒤에는 명령 이름과 인수가 옵니다. 껍데기
여기에서는 구문이 완전히 이해되지 않으며 작은따옴표와 큰따옴표 및 백슬래시만 이해됩니다.
makepp 전체에서와 마찬가지로 내부의 문자입니다. 명령 이름은 다음 중 하나의 기능으로 연결됩니다.
"씨_이름" 나머지 문자열을 인수로 사용하여 호출됩니다. 그런 기능이 가능하다면
찾을 수 없는 경우 이는 "perl" 블록에서 "run"을 호출하는 것과 동일합니다.

이를 통해 내장, makefile 제공 또는 외부 명령을 효율적으로 호출할 수 있습니다.
접두사 "&"가 선택된 이유는 이것이 Perl의 함수 호출자이기 때문입니다.
처음에는 Shell에서 불법입니다.

$(루트)/include/%.h: %.h
&ln $(입력) $(출력)

노에초
@ 일반적으로 각 쉘 명령은 실행될 때 인쇄됩니다. 그러나 첫 번째 단어의 경우
작업이 "noecho"(또는 "@" 문자로 시작하는 경우)이면 명령은
인쇄되지 않습니다. 예를 들어,

%.o: %.cxx
noecho $(LIBTOOL) --mode=compile $(CC) -c $(입력)

이는 libtool 명령이 실행될 때 인쇄되지 않음을 의미합니다. (리브툴
자체적으로는 일반적으로 실행하는 수정된 명령을 인쇄하므로
두 번 인쇄하세요.)

무시_오류
- 일반적으로 쉘 명령이 XNUMX이 아닌 상태를 반환하면 makepp가 중단됩니다.
명령이 실패했습니다. 그러나 일부 프로그램은 종료 시 상태를 잘못 설정하거나
실제로는 치명적이지 않고 전체를 중단해서는 안 되는 오류가 있을 수 있습니다.
편집. 다음을 지정하여 makepp가 반환 상태를 무시하도록 할 수 있습니다.
명령줄의 첫 번째 단어인 "ignore_error"(또는 첫 번째 문자인 "-")
예를 들어,

$(위조 배포):
ignore_error rm -r my_program-$(VERSION) # 이전 정크를 제거합니다.
&mkdir my_program-$(버전)
&cp $(파일) my_program-$(버전)
tar cf my_program-$(버전).tar my_program-$(버전)

이 명령은 디렉토리를 만들고 여기에 여러 개의 파일을 복사한 다음
배포를 위해 모든 것을 tar 파일에 넣습니다. 구석구석 깨끗이 닦아주는 것이 좋습니다
디렉토리의 이전 내용(이전에 거기에 뭔가가 있었다면)
첫 번째 줄이 하는 일. "rm"이 실패할 수 있지만 반환 상태는 무시됩니다.


메이크펄
이는 본질적으로 Perl 문과 동일하지만 다음과 같은 경우마다 수행됩니다.
makefile을 읽을 때가 아니라 규칙을 실행합니다. 첫 번째 변형은 일반 Perl입니다.
두 번째 변형은 먼저 Make 스타일 변수를 통해 명령문을 전달합니다.
확장.

신체의 버팀대를 놓는 두 가지 가능성에 대해서는 다음의 설명을 참조하십시오.
makepp_statements의 "perl_perlcode"입니다. 거기에 세 번째 변형이 설명되어 있습니다.
여기서는 의미가 없습니다. 모든 액션 라인을 들여쓰기해야 하기 때문입니다. 신호를 보내야 합니다
"die"를 호출하여 Perl 문이 실패했습니다.

규칙에 따라 Perl 문은 현재 다음을 제외하고 공통 하위 프로세스에서 평가됩니다.
윈도우. 즉, 모든 makefile 변수에 대한 읽기 액세스만 가능하다는 의미입니다. 그것은 또한
Perl이 아닌 작업을 실행하는 프로세스입니다. 따라서 exec 또는 종료를 호출하면 혼란스러울 것입니다.
makepp. 하지만 이는 미래에는 바뀔 수도 있습니다. Perl을 호출하는 효율적인 방법
스크립트에 대해서는 이전 항목 "&" 또는 "실행"을 참조하세요.

$(가짜 버전):
noecho perl {{ # Perl의 $(target) & $(VERSION):
print "이것은 ".f_target()"입니다. $VERSION\n";
}}
echo 이것을 쉘 명령과 혼합할 수 있습니다
-makeperl { print "이것은 $(target) $(VERSION)\n" }

여러 종류의 규칙이 있으며 각각 다른 목적을 가지고 있습니다.

명백한 규칙
타겟1 타겟2: 종속성1 종속성2 ...
수행할 작업

이 구문은 다음 중 하나를 수행하도록 지정합니다. target1 or target2, 모든 파일
종속성1, 종속성2등은 이미 만들어져 있어야 합니다. 그러면 주어진 행동은
대상을 만들기 위해 쉘에 의해 실행됩니다.

파일의 첫 번째 명시적 규칙은 기본 대상이며 지정하지 않으면 만들어집니다.
명령줄의 모든 대상.

전통적인 make 프로그램과 달리 makepp는 일반적으로 작업이 한 번 호출된다고 가정합니다.
(종속성이 없는 경우를 제외하고) 모든 대상을 만듭니다. 예를 들어, 하나의 호출
yacc는 이 규칙에 대한 두 출력 파일을 모두 생성합니다.

y.tab.c y.tab.h : 파서.y
$(YACC) -d 파서.y

make의 다른 구현에는 단일 명령 개념이 없다는 점에 유의하십시오.
여러 출력 파일을 생성하므로 여러 대상을 지정하면
대상당 한 번씩 규칙을 실행합니다. Makepp은 다음과 같은 경우 이 동작으로 되돌아갑니다.
이것은 구식 makefile입니다. 구체적으로 말하면 대상당 한 번씩 규칙을 실행합니다.
전체적으로 한 번만 사용하는 대신 다음 사항이 모두 참인 경우:

· 규칙 작업에는 자동 변수 $@이 언급되어 있습니다. (동의어 "$(output)" 또는
"$(target)"은 이 동작을 유발하지 않습니다.)

· 규칙 작업에 자동 변수 "$(outputs)"(또는 해당 동의어)가 언급되지 않습니다.
"$(대상)").

· 이는 패턴 규칙이 아니며 foreach 절이 없습니다.

예를 들어,

모든 테스트 설치:
$(SUBDIRS)의 하위 디렉터리에 대해; cd $$subdir && $(MAKE) $@; CD ..; 완료

makefile의 일반적인 관용구이며 makepp에서는 이를 지원합니다. (절대로 사용하면 안 된다는 점에 유의하세요.
작성하는 새 makefile에서 재귀 make를 수행합니다. "load_makefile" 문을 사용하거나
대신 암시적 makefile 로딩.)

각 대상에 대해 동일한 규칙을 한 번씩 실행하려는 경우(예: 대상이
유사한 명령이 있는 경우) 패턴 규칙(아래 참조) 또는
"foreach" 절. 예를 들어, 전통적인 make 프로그램을 사용한다면 다음과 같이 작성할 것입니다:

ABCD:
$@ > $@ 빌드할 작업 수행

makepp에서는 아마도 다음과 같이 작성하고 싶을 것입니다:

$(foreach) : : foreach abcd
$(output) > $(output)을 구축하기 위한 do_something

위조품 목표

A 위조품 목표 파일 시스템에 실제로 존재하지 않는 대상입니다. 그것은 단지
makepp가 일부 대상을 빌드하고 추가 명령을 실행하도록 하는 방법입니다.

일반적인 가짜 대상은 "all"이며 일반적으로 발생할 수 있는 모든 것을 유발하는 데 사용됩니다.
다음과 같이 빌드되도록 빌드되었습니다.

모두: prog1 prog2 하위 디렉터리/prog3 하위 디렉터리2/libmine.a
@&echo "다 끝났어요!"

"makepp all"을 입력하거나 makefile의 첫 번째 명시적 대상으로 all을 입력한 경우
(일반적입니다) 그냥 "makepp"라고 입력하면 모든 종속성이 다음과 같이 됩니다.
빌드되면 "All done!"이 인쇄됩니다. 이 시점에서 makepp은 파일을 찾습니다. ./모두
그리고 그것이 존재하지 않는다는 것을 알게 될 것이다. 큰 소리로 불평할 것입니다.

makepp이 파일을 기대하지 않도록 하려면 ./모두 종료하려면 다음과 같이 말해야 합니다.
가짜 표적. makefile에 다음과 같은 줄을 넣으십시오(차이는 없습니다).
어디):

.PHONY: 모두

때때로 더 편리한 동등한 대안은 "$(phony )"를 사용하는 것입니다.
함수는 다음과 같습니다.

$(가짜 모두): prog1 prog2 subdir/prog3 subdir2/libmine.a

한 메이크파일의 가짜 대상은 다른 메이크파일의 가짜 대상을 참조할 수 있습니다. 이것은
종종 다음과 같이 "깨끗한" 대상을 사용하여 수행됩니다.

# 최상위 메이크파일:
# 여기에는 많은 규칙과 것들이 있습니다
# ....
$(포니 클린): subdir1/clean subdir2/clean
&rm -fm my_program

그런 다음 하위 디렉터리에서 makefile은 다음과 같이 읽을 수 있습니다.

# 하위 디렉토리의 Makefile
# ...
$(포니 클린):
&rm -fm $(와일드카드 *.o *.a)

그러나 요즘에는 깨끗한 대상 대신 "makeppclean" 명령을 사용합니다.

와일드 카드

종속성 목록에 와일드카드를 지정하는 것이 안전합니다. 와일드카드는 파일뿐만 아니라 일치합니다.
존재하지만 makefile의 규칙에 따라 생성될 수 있는 파일입니다. 예를 들어,
디렉토리의 모든 .o 파일에서 라이브러리를 빌드하려면 다음과 같이 작성할 수 있습니다.

libmine.a: *.o
&rm -f $(출력)
ar cr $(출력) $(입력)

이것은 ".o" 파일이 아직 생성되지 않은 경우에도 작동합니다. 왜냐하면 makepp의
와일드카드는 아직 존재하지 않지만 빌드할 수 있는 파일과 일치합니다. 이것도 잡히겠네
나중에 규칙이 발견되는 파일(동일한 makefile 또는 아직 읽지 않은 파일) 이에
마지막 점은 알려진 규칙으로 제한되는 "와일드카드" 기능과 다릅니다.
확장되면 결과를 반환해야 하기 때문입니다.

Makepp은 모든 일반적인 셸 와일드카드("*", "?" 및 "[]")를 지원합니다. 그것은 또한
중간에 있는 디렉터리 수와 일치하는 와일드카드 "**"입니다. (이 아이디어는 도난당했습니다.
zsh에서.) 예를 들어 "**/*.c"는 모든 항목과 일치합니다. .c 전체 소스 트리의 파일.
"objects/**/*.o"는 다음과 모두 일치합니다. .o 하위 디렉터리에 포함된 파일 사물
또는 해당 하위 디렉터리 또는 해당 하위 디렉터리 중 하나입니다. "**" 와일드카드는
모든 수준의 디렉토리에 대한 소프트 링크를 따르십시오. 또한 가짜 대상을 반환하지 않습니다.

Makepp의 와일드카드는 존재하지만 읽을 수 없는 파일이나 디렉터리를 무시합니다. 후에
어쨌든 그러한 파일은 빌드 프로세스에서 사용할 수 없습니다. 읽을 수 없는 파일을
디렉토리는 주로 특정 파일을 자동으로 가져오는 것을 방지하는 데 유용합니다.
저장소.

초기 주장은 이것이 안전하다는 것이었습니다. 이것은 그것이 작동한다는 의미에서입니다.
파일이 이미 존재하거나 먼저 빌드해야 합니다. 그러나 그것은 의미에서 안전하지 않습니다
makepp에 의해 생성된 파일과 여전히 일치하지만 더 이상 규칙이 없습니다(예:
당신은 제거 .c 파일이지만, .o 파일이 아직 거기에 있습니다.) 이를 방지하려면 다음을 사용하십시오.
"--rm-stale" 옵션.

무늬 규칙
패턴 규칙은 일부 텍스트 패턴을 기반으로 적용되는 규칙입니다. 이것은 다음과 같은 데 사용됩니다.
전체 파일 클래스에 동일한 규칙을 적용합니다. 구문은 GNU make와 동일합니다.
패턴 규칙:

%.o: %.c
$(CC) -c $(입력) -o $(출력)

이는 "*.c"와 일치하는 현재 디렉터리의 모든 파일을 다음으로 변환할 수 있음을 의미합니다.
주어진 명령을 사용하여 해당 .o 파일.

여러 패턴 종속성이 제공될 수 있습니다. 예를 들어, 귀하의 경우 xyz.o 파일
해당하는 항목에 따라 다릅니다. xyz.cpp 파일 및 다음과 같은 파일에도 있습니다. moc_xyz.cflags 어느
컴파일러 옵션이 포함되어 있으며 이는 다음과 같이 표현될 수 있습니다.

%.o: %.cpp %.cflags
$(CXX) `cat $(stem).cflags` -c $(입력) -o $(출력)

여러 패턴 대상이 있을 수도 있습니다. 예를 들어,

%.tab.h %.tab.c : %.y
yacc -d $(입력)
&mv y.tab.h $(줄기).tab.h
&mv y.tab.c $(줄기).tab.c

일반적으로 패턴 규칙은 현재 디렉터리의 파일만 찾습니다. 강제로 할 수 있다
설정을 통해 현재 디렉터리와 그 아래의 모든 디렉터리를 검색합니다.

makepp_percent_subdirs := 1

예를 들어 makefile이나 명령줄의 첫 번째 패턴 규칙 앞에.

"%"와 와일드카드 "*" 사이에는 분명한 차이가 있지만 둘 다 일치합니다.
문자열: 와일드카드는 해당 시점에 완전히 사용된 파일 목록을 반환합니다. 그래서
이것은 모두에 달려있다 .o 여기에서 빌드 가능한 파일:

프로그램: *.o
$(LD) $(LDFLAGS) $(입력) -o $(출력)

"*"를 "%"로 바꾸면 이를 달성할 수 없습니다. 왜냐하면 후자는 하나씩 사용하기 때문입니다.
입력과 출력을 일치시켜 일치하는 각 줄기에 대해 내부적으로 하나의 규칙을 생성합니다.

정적인 무늬 규칙
정적 패턴 규칙은 제한된 파일 집합에만 적용되는 패턴 규칙입니다.

$(특수 모듈).o : %.o : %.cpp
$(CXX) -c $(입력) -o $(출력)

이는 패턴 규칙이 "$(SPECIAL_MODULES).o"에 있는 파일에만 적용된다는 의미입니다.

이는 대부분 GNU make와의 호환성을 위한 것입니다. foreach 규칙(아래 참조)은 더 많은 것입니다.
같은 일을 하는 강력한 방법.

각각 규칙
위의 패턴 규칙 구문은 거의 모든 빌드를 지원할 만큼 강력하지만
때로는 더 복잡한 작업을 수행해야 하는 경우도 있습니다. Makepp은 더 많은 것을 제공합니다
강력한 구문: 규칙에 대한 ":foreach" 절.

target_expression : dependency_expression : foreach 파일 목록
행위

가장 간단한 종류의 foreach 규칙은 적용이 제한된 패턴 규칙입니다.
특정 파일 목록에. 예를 들어 다음과 같은 패턴 규칙이 있다고 가정해 보겠습니다.
makepp 모두 컴파일하는 방법 .c 파일. 그러나 다음 목록이 있습니다. .c 당신이 사용하는 파일
뭔가 다른 걸 하고 싶어. 다음과 같이 할 수 있습니다.

# 모든 것에 적용되는 규칙은 다음과 같습니다.
%.o : %.c
$(CC) $(CFLAGS) -c $(입력) -o $(출력)

%.o : %.c : foreach $(SPECIAL_MODULES)
$(CC) $(SPECIAL_CFLAGS) -c $(입력) -o $(출력)

foreach 규칙을 더욱 강력하게 사용하면 변수가
파일 목록과 대상이 일치하는 각 파일에 "$(foreach)"가 차례로 설정되고
종속성 표현식이 평가됩니다. 파일 목록에는 와일드카드가 포함될 수 있으며 이는
아직 존재하지 않지만 빌드할 수 있는 파일도 일치합니다("와일드카드" 참조).
makepp_rules).

이것은 다루기 힘든 구문이지만 매우 유연합니다. "$(foreach)" 변수
표현에 어떤 식으로든 나타날 수 있습니다. 먼저, 패턴 규칙은 실제로
foreach 규칙의 특별한 경우입니다. 패턴 규칙

%.o : %.c
$(CC) $(CFLAGS) -c $(입력) -o $(출력)

다음과 정확히 동일합니다.

$(patsubst %.c, %.o, $(foreach)) : $(foreach) : foreach *.c
$(CC) $(CFLAGS) -c $(입력) -o $(출력)

(실제로 내부적으로는 대략적으로 그렇게 변환되어 있습니다.)

패턴 규칙이 적용되지 않는 ":foreach" 절을 사용하는 방법의 예는 다음과 같습니다.
충분해요, 당신이 좀 가지고 있다고 가정해보세요 .c 일종의 전처리기를 사용하여 작성된 파일
이는 다음과 같은 입력 파일로 사용됩니다. .k 확대. 당신은 그것들을 컴파일하고 싶습니다 .c 파일
평소와 다른 컴파일 옵션 세트 .c 일반 소스인 파일
파일. 다음과 같이 할 수 있습니다.

# 일반 .c 파일에 대한 규칙:
%.o : %.c
$(CC) $(CFLAGS) -c $(입력) -o $(출력)

# .k 파일에서 .c 파일을 만드는 규칙:
%.c : %.k
$(전처리기) $(입력) > $(출력)

# .k 파일로 만들어진 .c 파일에 대한 특수 빌드 규칙:
$(foreach:%.k=%.o) : $(foreach:%.c=%.k) : foreach *.k
$(CC) $(SPECIAL_CFLAGS) -c $(입력) -o $(출력)

(이것은 호출하는 대신 약간 더 간결한 대체 참조 구문을 사용합니다.
명시적으로 "patsubst"를 사용합니다.)

변수(여기서는 "CFLAGS")의 값을 변경하려는 것이 전부라면 주의하세요.
경우) 타겟별 변수를 사용하는 것이 더 편리한 경우도 있습니다.

유산 접미사 규칙
이전 버전과의 호환성을 위해 makepp는 이전 스타일 접미사 규칙을 지원합니다.

.접미사1.접미사2:
행위

에 해당하는

%.접미사2: %.접미사1
행위

하지만 기억하기가 훨씬 더 어렵습니다. (어떤 접미사가 먼저 나오나요?) 일반적으로 규칙이 나타납니다.
다음과 같은 레거시 메이크파일에서:

.co:
$(CC) $(CFLAGS) -c $*.c -o $*.o

이는 정확히 다음과 같습니다.

%.o : %.c
$(CC) $(CFLAGS) -c $(입력) -o $(출력)

서로 싸우는 규칙
파일을 만드는 방법이 여러 가지인 경우 makepp는 간단한 절차를 사용하여 다음을 수행합니다.
어떤 규칙을 사용할지 결정합니다.

· 파일 작성에 대한 명시적인 규칙이 충돌하는 것은 오류입니다.

· 패턴 규칙과 와일드카드가 포함된 foreach 규칙은 명시적 규칙을 재정의하지 않습니다. 따라서
명시적 규칙을 사용하여 패턴 규칙에 대한 예외를 지정할 수 있습니다. (단순히 참고하세요.
":foreach" 절을 사용한다고 해서 어떤 것이 패턴 규칙이 되는 것은 아닙니다. 그것은 있어야합니다
":foreach" 절에서 파일 이름의 일부로 와일드카드(예: "*" 또는 "?")를 사용합니다. 그렇다면
명시적인 파일 목록일 뿐이며 각 파일에 대한 명시적인 규칙으로 처리됩니다.
파일.)

· 서로 다른 makefile에서 충돌하는 패턴 규칙이 나오는 경우 "nearer"의 규칙
makefile은 "더 먼" makefile의 규칙을 무시합니다. "Nearer"는 makefile이
디렉토리 계층 구조에서 대상에 더 가깝게 위치합니다(예:
makefile이 실행되는 디렉토리에 상대적인 대상이 더 짧습니다). 이 경우
메이크파일과 로드된 메이크파일의 규칙을 구별하지 않습니다.
최신이 사용됩니다.

즉, 파일의 모든 파일에 적용되는 패턴 규칙을 지정할 수 있습니다.
전체 디렉토리 트리는 최상위 makefile에 있지만 다음에서 이를 재정의할 수 있습니다.
하위 레벨 makefile. 예를 들어 최상위 makefile에는 다음이 포함될 수 있습니다.

%.o : %.c : foreach **/*.c
$(CC) $(CFLAGS) -c $(입력) -o $(출력)

하위 디렉터리 중 하나에 다음과 같은 makefile이 있을 수 있습니다.

%.o : %.c
$(CC) $(SPECIAL_CFLAGS) -c $(입력) -o $(출력)

· 추론 체인이 더 짧은 패턴 규칙이 다른 패턴보다 선호됩니다.
규칙. 예를 들어, 다음 규칙이 있는 경우(다음의 예를 기반으로 함)
리눅스 커널):

%.s: %.c
$(CC) -s $(입력) -o $(출력)

%.o: %.s
$(AS) $(입력) -o $(출력)

%.o: %.c
$(CC) -c $(입력) -o $(출력)

"xyz.o"를 빌드해야 하는 경우 중간 ".s" 파일을 빌드한 다음
처음 두 규칙을 사용하여 어셈블러를 통해 이를 실행하거나
마지막 규칙을 사용하는 ".o" 파일입니다. 마지막 규칙은 더 적기 때문에 선호됩니다.
추론 사슬의 단계(XNUMX개가 아닌 XNUMX개).

· 메이크파일의 뒷부분에 있는 패턴 규칙은 이전의 패턴 규칙을 재정의합니다. (이것은
GNU make에서 거꾸로.) 이는 보다 일반적인 규칙을 적용해야 함을 의미합니다.
더 일찍, 더 구체적인 규칙은 나중에. 예를 들어,

%.o: %.c # 일반적인 컴파일 규칙.
동작

특수_%.o: 특수_%.c # 다음과 같은 파일에 대한 특수 규칙
다른 작업 # "special_" 접두사.

통치 옵션
makepp이 실행하는 방법을 수정하기 위해 추가 옵션을 제공해야 하는 경우도 있습니다.
규칙. 이 옵션은 다음을 포함하는 줄에서 ":optionname value"로 지정됩니다.
종속성 또는 다음 줄에 있습니다.

별도의 줄에 옵션을 제공하면 동일한 옵션을 사용할 수 있습니다.
makepp와 전통적인 make를 사용한 makefile. 예를 들어,

대상 : 종속성
: 서명 target_newer
행위

": 서명" 줄을 해석하기 때문에 전통적인 Unix 제작에서는 잘 작동합니다.
쉘 명령으로 사용되며 콜론으로 시작하는 명령은 아무 작업도 수행하지 않습니다.

:빌드_캐시 /경로/대상/빌드/캐시
대상 : 종속성
: build_cache /put/cache/files/over/there
행위

이 규칙에 의해 생성된 파일에 사용할 빌드 캐시의 경로를 지정합니다. 이것
"build_cache" 문 또는 "--build-cache" 명령의 효과를 무시합니다.
이 규칙에 대한 행 옵션(있는 경우)입니다. 빌드에 대한 자세한 내용은 makepp_build_cache를 참조하세요.
캐시.

경로 대신 "없음"을 지정하면 이에 대한 빌드 캐시가 비활성화됩니다.
특별한 규칙. 이는 저장하려는 파일의 디스크 공간 낭비를 방지하는 데 유용할 수 있습니다.
캐시하는 데 유용하지 않다는 것을 알고 있습니다. 왜냐하면 캐시가 결코 유용하지 않을 것이라고 확신하기 때문입니다.
재사용되거나 너무 빨리 구축되어 캐싱할 가치가 없기 때문입니다.

:빌드_체크 build_check_method
대상 : 종속성
: build_check target_newer
행위

이는 makepp에게 대상을 다시 빌드해야 하는지 결정하는 데 사용할 알고리즘을 알려줍니다.
자세한 내용은 makepp_build_check를 참조하세요. 이는 다음의 효과를 무시합니다.
"build_check" 문 또는 "--build-check-method" 명령줄 옵션(있는 경우)
이 규칙.

:환경 변하기 쉬운 ...
명명된 환경 변수의 값에 대한 종속성을 추가합니다. 만약 그들 중 누구라도
이전 빌드와 다르면 대상이 오래된 것으로 간주됩니다.
build_check 메소드가 지시합니다. (다음을 제외한 모든 내장 빌드 확인 방법)
target_newer는 이를 존중합니다.)

VARIABLE은 "PATH_VARIABLE의 파일 이름"(따옴표) 형식일 수 있습니다.
콜론으로 구분된 첫 번째 디렉터리의 경우 대상이 오래된 것으로 간주됩니다.
파일명이 존재하는 PATH_VARIABLE 값이 지난 빌드와 다릅니다.
이는 PATH_VARIABLE이 변경될 때 대상을 다시 빌드하는 것을 방지하는 데 사용할 수 있습니다.
관련 없는 방법.

:보내다 명령 ...
각 셸 작업(Perl 작업이나 Perl 명령은 제외)을 "sh -c '...'"로 묶습니다.
명령 앞에 접두사를 붙이지만 대상은 명령에 의존하지 않는다고 가정합니다.
이는 작업 대기열 시스템에 작업을 보내려는 경우 유용하지만 결과는 다음과 같습니다.
큐잉 매개변수뿐만 아니라 큐잉 여부와도 독립적인 것으로 가정됩니다.
시스템이 전혀 사용되지 않습니다.

:포함하다 파일_or_패턴
규칙은 컴파일러에 따라 다릅니다.

%.o : %.c
: %.d 포함 : 서명 C
gcc -MD -c ...

%.o : %.c
: %.u 포함 : 서명 C # IBM은 다른 접미사를 사용합니다.
xlc -M -c ...

sub dependency { # Microsoft의 채팅을 유용한 형식으로 전환
s/\$/\$\$/g;
s/(참고: 파일 포함: *)?(.+?)\r?\n/$1 ? "'$2' " : "'".f_output()."': "/e;
}
%.o : %.c
: %.d 포함 : 서명 C
cl -showIncludes -c ... >$(stem).d
&sed &dependent -o +<$(줄기).d

일부 컴파일러(위의 gcc와 같은 Intel의 icc 또는 IBM의 xlc)는 종속성을 생성할 수 있습니다.
즉시 파일. 즉, 컴파일하는 동안 makepp이 수행할 수 있는 makefile을 작성합니다.
포함하다. makepp의 스캐너에 비해 장점은 100% 보장된다는 것입니다.
맞습니다, 우리가 가까이 다가갈 수 있는 곳은 바로 여기입니다.

이 옵션은 이를 특별한 방법으로 활용합니다: 파일이 존재하지 않는 경우, 즉
일반적으로 첫 번째 빌드에서는 정상적인 스캔이 발생합니다. 하지만 파일이 있으면 안 됩니다.
스캔이 발생합니다(이것이 위에서 스마트 서명을 지정한 이유입니다. 스캔하지 않음
타임스탬프와 크기의 멍청한 기본값으로 돌아갑니다). 대신에 파일이 포함됩니다.
규칙을 실행합니다. 규칙을 성공적으로 실행한 후에는 무엇이든 잊어버립니다.
파일이 오래되었을 수 있으므로 처음으로 읽으십시오. 대신에 그것은 읽습니다
파일이 변경된 경우 최신 빌드 정보를 얻기 위해 다시 파일을 업데이트합니다.

경고: 이는 본질적으로 신뢰할 수 없습니다. 종속성 파일은 다음에 의해 생성됩니다.
종속된 규칙입니다. 반면에 컴파일러는 모든 것을 알고 있습니다.
그것은 makepp가 일반적으로 무시하는 내부 하위 포함입니다. 이것이 신뢰성이다
컴파일러 패치가 하위 포함만 수정하는 경우에만 이점이 있습니다. 그만큼
가격은 makepp가 결국 더 많은 파일을 보게 되므로 시간이 걸린다는 것입니다.

"#include" 문을 제거하면 문제가 발생합니다. 해당 파일:
이는 지난 번 종속성 파일에서 계속 언급될 것입니다.
필요합니다. 이러한 경우 종속성을 제거하려면 종속성 파일을 편집해야 합니다.
더 이상 이행할 수 없습니다.

이 기능은 빌드 캐시에서 파일을 가져오기 때문에 빌드 캐시와 함께 사용할 수 없습니다.
파일에 대한 모든 것을 알아야 합니다. 그러나 종속성 파일은 해당 파일에 따라 다릅니다.
makepp는 파일을 읽어서 알게 됩니다. 이러한 순환 종속성은 일반적으로
안정적인 빌드 시스템에서 가능합니다. 재구축 후에는 예외입니다.
종속성 파일을 다시 읽으면 모든 것이 다시 정확해집니다.

저장소에 빌드하면 makepp는 다음에서 종속성 파일을 선택합니다.
하나를 포함하는 첫 번째 저장소. 이는 첫 번째 파일을 사용하는 다른 파일과 다릅니다.
예상되는 서명으로. 이는 빌드 캐시보다 낫습니다.
서명이 없으면 파일을 찾을 수도 없습니다.

:마지막 기회
다음과 같은 개방형 규칙을 활성화합니다.

%.foo foo%.bar: :last_chance
&에코 $@ -o $@
&cp $(출력)

이와 같은 규칙은 본질적으로 무한한 수의 대상을 생성할 수 있기 때문에
이 규칙의 대상은 $(wildcard) 함수 또는 패턴 규칙과 일치하지 않습니다.
다른 것이 이미 대상을 구체적으로 참조하여 규칙을 인스턴스화했습니다.
또한 "--rm-stale"이 지정되면 이전 대상에서 남은 대상이
makepp 실행을 빌드하는 유일한 방법이 last_chance 규칙을 통하는 경우에는 makepp 실행이 오래되어 나타납니다.
이는 아직 대상에 대해 인스턴스화되지 않았으며 이는 바람직한 동작입니다.
와일드카드를 잘못 사용하면 빌드가 더 일관되게 실패합니다.
이전 실행의 목표와 일치합니다.

":last_chance" 옵션은 특별한 행동에 주의를 환기시키기 위한 것입니다.
와일드카드 일치에 관한 규칙입니다.

:파서 파서
이는 makepp에게 파일 감지(포함) 명령을 구문 분석하는 방법을 알려줍니다. 대개,
makepp는 명령 자체의 단어를 기반으로 이를 수행하는 방법을 추측합니다(참조:
자세한 내용은 makepp_scanning을 참조하세요). 그러나 makepp이 잘못 추측한 경우 다음을 수행할 수 있습니다.
다음과 같이 파서를 명시적으로 나타냅니다.

%.o: %.abc
: 파서 c_compilation
여기서 행동

이로 인해 makepp는 C/C++에서 수행하는 것과 동일한 구문 분석 및 검색을 수행합니다.
빌드 명령(작업을 C 컴파일로 인식하지 못하더라도).

기본 구문 분석기는 명령에 따라 다릅니다. ":parser" 옵션을 지정하지 않으면,
그런 다음 각 명령의 첫 번째 단어를 검사합니다. 예를 들어 컴파일이나 링크의 경우
명령을 실행하면 makepp는 "c_compilation" 구문 분석기를 사용합니다. 또는 명령이 다음과 같은 경우
GNU 변형, "gcc_compilation". 파서가 발견되지 않으면 "없음" 파서를 사용합니다. 을 위한
이에 대한 자세한 내용을 알고 싶거나 자신만의 파서를 작성하거나 makepp의 내용을 변경하려는 경우
기본 파서, makepp_scanning을 참조하세요.

이는 규칙의 모든 명령에 적용되며 원하는 것이 아닐 수도 있습니다.

%.o: %.c : 파서 ​​c-컴파일
@echo '$(출력) 빌드'
@funny_cc ...

이는 또한 "echo"를 컴파일러로 해석하고 인수 'Building'을 추론합니다.
mymodule.o'를 암시적 종속성으로 사용합니다. 이로 인해 불만이 제기될 것입니다.
그런 파일을 만드는 방법을 모릅니다. 이 경우에는 다음이 더 나을 것입니다.
"레지스터_파서". 거기에서 방법에 대한 설명을 찾을 수 있습니다. 파서 다음 중 하나로 주어질 수 있습니다.
클래스 이름 또는 함수 이름으로.

:서명 서명_방법
대상 : 종속성
: 시그니처 md5
행위

이는 makepp에게 종속성이 변경되었는지 확인하는 데 사용할 알고리즘을 알려줍니다.
자세한 내용은 makepp_signatures를 참조하세요. 포함된 서명 방법
makepp 배포판은 "plain", "md5", "C" 또는 "c_compilation_md5"입니다.
"공유_객체". 이는 "-m" 또는
"--signature-method" 명령줄 옵션 또는 "signature" 문을 사용합니다.

이달의 스페셜 문자
Makepp은 콜론이나 공백과 같은 특수 문자가 포함된 파일 이름을 지원할 수 있습니다.
예를 들어 "b:thing" 파일에서 "a:thing"이라는 파일을 생성한다고 가정해 보겠습니다.
다음과 같이 규칙을 작성할 수 없습니다.

a:thing : b:thing # 구문 오류입니다.
&cat $(입력) -o $(출력)

makepp은 어떤 콜론이 종속성과 대상을 분리하는지, 어떤 콜론이 종속성인지 알 수 없기 때문입니다.
파일 이름의 일부입니다. 대신 다음과 같이 이름을 따옴표로 묶으세요.

"a:것" : "b:것"
&cat $(입력) -o $(출력)

이제 규칙은 분명해졌습니다.

Makepp의 인용 구문은 쉘의 인용 구문과 매우 유사합니다. 예를 들어, 단일을 사용할 수 있습니다.
큰따옴표 대신 따옴표를 사용하거나 백슬래시를 사용하여 특수 문자를 이스케이프할 수 있습니다.

a\:thing : 'b:thing'
&cat $(입력) -o $(출력)

예를 들어 파일 이름이 "'"!;\$"라고 가정합니다. 이제 그러한 파일 이름을 원하는 이유는 무엇입니까?
잘 모르겠지만 makepp(및 셸)에 지정할 수 있는 몇 가지 방법이 있습니다.

\''"!;\$$'
"'\"!;\\$$"

makepp가 따옴표를 제거할 때와 쉘이 제거할 때 주의를 기울이십시오. Makepp은 다음과 같이 본다.
다음과 같은 경우에만 따옴표를 사용하세요.

· "ifeq" 테스트 계열

· 규칙 콜론 전후

· makepp 내장 명령에서

· 파일과 관련된 함수에서

쉘과 달리 makepp는 따옴표를 변수에 할당하는 동안 따옴표를 확장하지 않습니다. 따라서
다음 규칙은 동일합니다.

FILE = '공백이 있는 이름'
x := $(print $(FILE)) # 따옴표가 아직 있는지 확인하기 위한 것입니다.
$(FILE): # makepp에 의해 제거된 단일 파일 주위의 따옴표
&echo hello -o$(FILE) # makepp에 의해 제거된 단일 파일 주위의 따옴표
echo 거기 >>$(FILE) # 쉘에 의해 제거된 단일 파일 주위의 인용부호
'공백이 있는 이름':
&echo hello -o'공백이 있는 이름'
echo 거기 >>'$(output)' # 위에서 따옴표가 제거되었으니 다시 추가하세요

(셸과 달리) "$"로 시작하는 변수는 단일 내부에서도 확장됩니다.
인용 부호. 달러 기호는 따옴표나 백슬래시로 보호할 수 없습니다. 리터럴을 얻으려면
달러 기호, 이중 달러 기호를 사용하세요. 예:

$(가짜 모두):
@&echo 이것은 달러 기호입니다: $$
@for val in abcd; echo $$val; 완료

일반적으로 모든 특수 문자를 인용하여 처리할 수 있어야 합니다.
어떤 면에서는. 여기에는 공백, 제어 문자 등이 포함됩니다. 그러나
현재 makepp의 주석 제거는 다소 단순하며 모든 "#" 문자는
앞에 공백이 있으면 인용 방법에 관계없이 주석으로 해석됩니다.

대상 또는 종속성 이름이 "$(output)"과 같은 자동 변수에 입력되면
따옴표와 백슬래시는 제거됩니다. 즉, 참조하려는 경우
액션에서 파일 이름을 입력하려면 다음과 같이 다시 인용해야 할 것입니다.

"공백이 있는 파일 이름":
echo "특수 내용" > "$@"

$@ 주위에 따옴표를 넣지 않으면 쉘에 다음 명령이 표시됩니다.

echo "특별 내용" > 공백이 포함된 파일 이름

"공백이 포함된 특수 콘텐츠 파일 이름"이라는 문자열을 다음 파일에 씁니다. a.
이것은 아마도 당신이 원하는 것이 아닐 것입니다.

onworks.net 서비스를 사용하여 온라인으로 makepp_rules 사용


무료 서버 및 워크스테이션

Windows 및 Linux 앱 다운로드

Linux 명령

Ad