단점 - 클라우드에서의 온라인

프로그램:

이름

단점 - 소프트웨어 구축 시스템

기술

버전 2.2.0에 대한 가이드 및 참조

저작권 (c) 1996-2000 자유 소프트웨어 재단, Inc.

이 프로그램은 무료 소프트웨어입니다. 다음 조건에 따라 재배포 및/또는 수정할 수 있습니다.
자유 소프트웨어 재단에서 발행한 GNU 일반 공중 사용 허가서; 어느 하나
라이센스 버전 2 또는 (귀하의 선택에 따라) 이후 버전.

이 프로그램은 유용할 것이라는 희망으로 배포되지만 어떠한 보증도 하지 않습니다.
상품성 또는 특정 목적에의 적합성에 대한 묵시적 보증도 없이.
자세한 내용은 GNU 일반 공중 사용 허가서를 참조하십시오.

이 프로그램과 함께 GNU 일반 공중 사용 허가서를 받았어야 합니다.
COPYING 파일을 참조하세요. 그렇지 않다면 Free Software Foundation, Inc., 59 Temple에 편지를 보내십시오.
장소 - Suite 330, Boston, MA 02111-1307, USA.

개요

단점 주로 소프트웨어를 구축하기 위한 시스템이지만,
이전 소프트웨어 구축 시스템. 단점은 처음부터 거래까지 설계되었습니다.
여러 소스 디렉터리에 분산된 소프트웨어를 구축하면 쉽게 가능합니다. 단점
간단하고 이해하기 쉽고 유지 관리가 쉬운 빌드 스크립트를 쉽게 만들 수 있습니다.
Cons는 복잡한 소프트웨어를 쉽고 정확하게 재현할 수 있도록 보장합니다.

Cons는 이 모든 것을 달성하기 위해 다양한 기술을 사용합니다. 구성 스크립트는 단지
Perl 스크립트를 사용하면 이해하기 쉽고 매우 유연합니다. 전역 범위 지정
변수는 정보를 공유하기 위한 가져오기/내보내기 메커니즘으로 대체되었습니다.
각 스크립트의 가독성과 유지 관리성이 크게 향상되었습니다.
건설 환경 소개되었습니다: 이것은 다음을 캡처하는 Perl 객체입니다.
빌드 프로세스를 제어하는 ​​데 필요한 정보입니다. 다양한 환경이 사용됩니다
빌드 트리에서 제품을 생성하기 위해 다른 의미가 필요한 경우. 단점
자동 종속성 분석을 구현하고 이를 사용하여 전체를 전역적으로 순서화합니다.
짓다. 변형 빌드는 단일 소스 트리에서 쉽게 생성됩니다. 지능형 빌드
현지화된 변경 작업을 할 때 하위 설정이 가능합니다. 재정의는 다음과 같이 설정할 수 있습니다.
스크립트를 수정하지 않고도 빌드 지침을 쉽게 무시할 수 있습니다. MD5 암호화
서명 파생된 파일과 연결되어 있으며 여부를 정확하게 결정하는 데 사용됩니다.
특정 파일을 다시 작성해야 합니다.

위의 모든 기능과 그 이상을 제공하면서도 Cons는 여전히 간단하고 사용하기 쉽습니다. 이것은,
이 문서의 나머지 부분을 읽으면서 명확해지기를 바랍니다.

단점? 지원 하다?

단점은 확인 대사. 다음 단락에서 우리는 그 중 몇 가지를 살펴봅니다.
make의 바람직하지 않은 특성과 make를 기반으로 하는 일반적인 빌드 환경
Cons의 개발에 동기를 부여했습니다.

짓다 복잡성

모든 규모의 전통적인 제작 기반 시스템은 상당히 복잡해지는 경향이 있습니다. 오리지널 메이크
유틸리티와 그 파생 상품은 다양한 방식으로 이러한 경향에 기여해 왔습니다. 메이커는
여러 디렉터리에 분산되어 있는 시스템을 다루는 데는 능숙하지 않습니다. 다양한 작업-
이 어려움을 극복하기 위해 주변이 사용됩니다. 일반적인 선택은 make가 호출하는 것입니다.
빌드의 각 하위 디렉터리에 대해 반복적으로 실행됩니다. 이로 인해 코드가 복잡해집니다.
변수가 어떻게 설정되는지, 변수 설정이 어떤 영향을 미치는지 불분명한 경우가 많습니다.
전체적으로 빌드에 영향을 미칠 것입니다. make 스크립팅 언어가 점차 확장되었습니다.
더 많은 가능성을 제공하기 위해 노력했지만 이는 대부분 이미
지나치게 확장된 언어. 종종 빌드는 다음을 제공하기 위해 여러 단계로 수행됩니다.
한 디렉토리에서 다른 디렉토리로 제품을 적절하게 전달합니다. 이는 추가를 나타냅니다.
빌드 복잡성이 증가합니다.

짓다 재현성

모든 제작의 골칫거리는 항상 종속성을 올바르게 처리하는 것이었습니다. 가장 자주,
단일 디렉토리 내에서 합리적인 종속성 작업을 수행하려고 시도했지만 실패했습니다.
디렉토리 간 작업을 수행하려는 진지한 시도가 이루어졌습니다. 종속성이 있는 경우에도
올바르게 작동하는지 확인하기 위해 간단한 타임스탬프 비교에 의존합니다.
종속 파일과 관련하여 파일이 오래되었습니다. 일반적으로 파일에 적합하지 않습니다.
파일을 다시 파생해야 하는 시기를 결정합니다. 예를 들어 외부 라이브러리가
재구축된 후 제자리에 '스냅'되면 새로 생성된 파일의 타임스탬프가
마지막 로컬 빌드보다 더 빠르겠죠. 표시되기 전에 빌드되었기 때문입니다.

변형 빌드

Make는 변형 빌드를 처리하기 위한 제한된 기능만 제공합니다. 확산되면서
하드웨어 플랫폼과 디버깅 가능한 코드와 최적화된 코드의 필요성,
이러한 변형을 쉽게 만드는 것이 필수적입니다. 더 중요한 것은 변형이 생성되면
변종을 분리하거나 재현할 수 있는 것이 중요합니다.
원본 또는 변형을 마음대로. make를 사용하면 빌드를 분리하는 것이 매우 어렵습니다.
소스와 별도로 여러 빌드 디렉터리. 그리고 이 기술을 사용하지 않으면
어떤 변종이 존재하는지 특정 시점에 보장하는 것도 사실상 불가능합니다.
완전한 재구축에 의지하지 않고 트리.

저장소

Make는 존재하는 코드로부터 소프트웨어를 구축하는 데 제한된 지원만 제공합니다.
중앙 저장소 디렉토리 구조. GNU make의 VPATH 기능(및 기타
구현)은 이를 제공하기 위한 것이지만 예상대로 작동하지 않습니다.
분석 초기에 대상 파일의 경로를 VPATH 이름으로 변경하므로
VPATH 디렉토리에서 모든 종속성을 검색합니다. 올바른 발전을 보장하기 위해
빌드를 수행하려면 로컬 빌드 디렉터리에 파일을 생성하고
로컬에 의존하는 코드 저장소(Make 용어로 VPATH 디렉토리)의 모든 파일
파일이 제대로 다시 빌드됩니다. 이것은 많은 코딩 없이는 VPATH에서는 불가능합니다.
복잡한 저장소 지식을 makefile에 직접 입력합니다.

유지 it 간편한 설치

위에서 make의 몇 가지 어려움을 언급했습니다. 이번과 이후에는
섹션에서는 단점을 소개하고 이러한 문제가 어떻게 해결되는지 보여줄 것입니다.

펄 스크립트

단점은 Perl 기반입니다. 즉, Cons 스크립트는--징집 과 건설하다 파일, 이에 상응하는
에 Makefile or 메이크 파일--모두 Perl로 작성되었습니다. 이는 즉각적인 이점을 제공합니다.
스크립트를 작성하는 언어는 친숙합니다. 당신이 Perl이 아니더라도
프로그래머라면 Perl이 기본적으로 단순한 선언적 언어라는 것을 아는 것이 도움이 됩니다.
잘 정의된 제어 흐름과 친숙한 의미 체계를 갖추고 있습니다. 행동하는 변수가 있습니다
기본적으로 서브루틴, 제어 흐름 등을 기대하는 방식입니다. 거기
Cons에 대해 도입된 특별한 구문은 없습니다. Perl을 스크립트 언어로 사용
종종 복잡한 문제에 대한 적절한 솔루션을 표현하는 작업을 단순화합니다.
빌드 요구 사항.

안녕하세요 세계!

다음 논의를 뒷받침하기 위해 다음을 구축할 수 있습니다. 안녕하세요 세계! C
단점이 있는 애플리케이션:

$env = 새로운 단점();
프로그램 $env 'hello', 'hello.c';

이 스크립트를 디렉터리에 설치하는 경우 스크립트 이름을 지정합니다. 건설하다을 만들고
안녕하세요.c 소스 파일을 같은 디렉터리에 저장한 다음 `cons hello'를 입력하여 빌드할 수 있습니다.
응용 프로그램 :

단점 % 안녕하세요
cc -c 안녕하세요.c -o 안녕하세요.o
cc -o 안녕하세요 안녕하세요.o

건설 환경

Cons의 주요 단순화는 다음과 같은 아이디어입니다. 구조 환경. 건설
환경은 대상 키/값 쌍 세트와 방법.
Cons에게 무언가를 빌드하는 방법을 알려주려면 다음을 통해 적절한 메소드를 호출해야 합니다.
적절한 건축 환경. 다음 예를 고려하십시오.

$env = 새로운 단점(
CC => 'gcc',
LIBS => 'libworld.a'
);

프로그램 $env 'hello', 'hello.c';

이 경우 기본 구성 환경을 그대로 사용하는 대신
대신 GNU C 컴파일러와 동등한 것이 사용되도록 `CC' 값을 재정의했습니다. 부터
이 버전의 안녕하세요 세계! 도서관이 필요하고, libworld.a, 우리는 다음을 지정했습니다.
이 환경에 링크된 프로그램은 해당 라이브러리와 링크되어야 합니다. 도서관의 경우
이미 존재하지만, 그렇지 않은 경우에는 다음 명령문도 포함해야 합니다.

라이브러리 $env 'libworld', 'world.c';

이제 'cons hello'를 입력하면 프로그램이 링크되기 전에 라이브러리가 구축됩니다.
물론 `gcc'는 두 모듈을 모두 컴파일하는 데 사용됩니다:

단점 % 안녕하세요
gcc -c 안녕하세요.c -o 안녕하세요.o
gcc -c 세계.c -o 세계.o
ar r libworld.a world.o
ar: libworld.a 생성
ranlib libworld.a
gcc -o 안녕하세요 hello.o libworld.a

Automatic 과 완전한 의존 분석

Cons를 사용하면 종속성이 자동으로 처리됩니다. 이전 예를 계속해서 참고하세요.
우리가 수정할 때 world.c, 월드.오 다시 컴파일되고, libworld.a 재창조되고, 안녕하세요
다시 연결됨:

% vi world.c
[편집하다]
단점 % 안녕하세요
gcc -c 세계.c -o 세계.o
ar r libworld.a world.o
ar: libworld.a 생성
ranlib libworld.a
gcc -o 안녕하세요 hello.o libworld.a

이것은 비교적 간단한 예입니다: Cons ``knows'' 월드.오 ~에 달려있다 world.c, 때문에
종속성은 `Library' 메소드에 의해 명시적으로 설정됩니다. 그도 그걸 알고 있어 libworld.a
~에 달려있다 월드.오 그 안녕하세요 ~에 달려있다 libworld.a, 모두 비슷한 이유로.

이제 그것은 밝혀졌습니다 안녕하세요.c 인터페이스 정의 파일도 포함됩니다. 세계.h:

% 이맥스 월드.h
[편집하다]
단점 % 안녕하세요
gcc -c 안녕하세요.c -o 안녕하세요.o
gcc -o 안녕하세요 hello.o libworld.a

콘스는 그걸 어떻게 알아? 안녕하세요.c 포함 세계.h, 그 안녕하세요. 그러므로 반드시
다시 컴파일? 지금은 여부를 고려할 때 다음과 같이 말하는 것으로 충분합니다. 안녕하세요. 이다-
현재까지 Cons는 종속성을 위해 스캐너를 호출합니다. 안녕하세요.c. 이 스캐너는
포함된 파일 안녕하세요.c 그 이상의 추가 종속성 목록을 작성하려면
Cons 스크립트에 의해 명시적으로 만들어졌습니다. 이 프로세스는 재귀적입니다.
포함된 파일도 검사됩니다.

이거 비싼거 아니야? 대답은 - 상황에 따라 다릅니다. 대규모 시스템의 전체 구축을 수행하는 경우,
스캔 시간은 중요하지 않습니다. 대규모 시스템을 재구축하는 경우 단점은 다음과 같습니다.
아무것도 하지 않아도 된다고 결정하기 전에 그것에 대해 생각하는 데 상당한 시간을 소비합니다.
완료되었습니다(만드는 것보다 반드시 더 많은 시간은 필요하지 않지만!). 좋은 소식은 Cons가 해낸다는 것입니다.
현지화된 변경 작업을 수행할 때 빌드를 지능적으로 하위 집합으로 만드는 것이 매우 쉽습니다.

Automatic 글로벌 빌드 시퀀싱

Cons는 완전하고 정확한 종속성 분석을 전 세계적으로 수행하기 때문에
Cons는 이 정보를 사용하여 전체 빌드를 완전히 제어할 수 있습니다. 시퀀싱
빌드의. 이 순서는 위의 예에서 분명하며 다음과 동일합니다.
전체 종속성 세트가 주어지면 make를 기대할 수 있습니다. 단점을 사용하면 이것이 확장됩니다.
더 큰 다중 디렉터리 빌드에 사소하게 적용됩니다. 결과적으로 관련된 모든 복잡성은
다중 패스 계층 구조를 포함하여 빌드가 올바르게 구성되었는지 확인합니다.
빌드--제거되었습니다. 이에 대해서는 다음 섹션에서 더 자세히 논의하겠습니다.

건물 넓은 나무-아직도 다만 as 간편한 설치

A 계층 of 빌드 스크립트

Cons의 더 큰 빌드는 다음과 같은 계층 구조를 생성하여 구성됩니다. 빌드 스크립트. 상단에
트리에는 다음과 같은 스크립트가 있습니다. 건설하다. 규칙에 따라 나머지 스크립트는 각각 다음과 같습니다.
라는 징집. 이 스크립트는 매우 간단하게 `Build'를 통해 함께 연결됩니다.
'내보내기' 및 '가져오기' 명령.

XNUMXD덴탈의 짓다 명령

`Build' 명령은 다음 목록을 가져옵니다. 징집 파일 이름을 지정하고 해당 파일이
빌드에 포함됩니다. 예를 들어:

빌드 qw(
드라이버/디스플레이/징병
드라이버/마우스/징병
파서/징집병
공익사업/징집병
);

이는 빌드 스크립트의 간단한 XNUMX단계 계층 구조입니다. 징집 파일
최상위 레벨에 언급되어 있습니다. 건설하다 파일. 트리의 모든 디렉터리가 아니라는 점에 유의하세요.
반드시 이와 관련된 빌드 스크립트가 있어야 합니다.

이는 다중 레벨 스크립트로 작성될 수도 있습니다. 예를 들어, 건설하다 파일은 아마도
다음 명령을 포함합니다:

빌드 qw(
파서/징집병
운전사/징집병
공익사업/징집병
);

그리고 징집 에 파일을 드라이버 디렉토리에는 다음이 포함될 수 있습니다.

빌드 qw(
디스플레이/징병
마우스/징집병
);

경험에 따르면 이전 모델이 좀 더 이해하기 쉽습니다.
전체 구성 트리가 최상위 레벨에 배치됩니다. 하이브리드 방식은
또한 가능합니다. 별도로 유지 관리되는 구성 요소로 통합되어야 합니다.
예를 들어 빌드 트리는 한 위치에서 빌드 트리에 연결될 수 있지만 자체적으로 정의할 수 있습니다.
건설 계층.

기본적으로 Cons는 작업 디렉토리를 다음을 포함하는 디렉토리로 변경하지 않습니다.
보조적인 징집 파일이 포함되어 있습니다. 이 동작은 다음을 통해 빌드에 활성화할 수 있습니다.
지정, 최상위 수준 건설하다 파일 :

징집병_chdir 1;

활성화되면 Cons는 자회사로 변경됩니다. 징집 파일이 포함된 디렉터리
해당 파일을 읽는 동안 파일을 읽은 후 최상위 디렉터리로 다시 변경합니다.
처리되었습니다.

이 동작은 일부 향후 버전의 Cons에서 기본값이 될 것으로 예상됩니다.
이 전환을 준비하기 위해 Cons가 빌드의 최상위에 유지될 것으로 기대하는 빌드
자회사에서 읽는 동안 징집 파일은 이 기능을 명시적으로 비활성화해야 합니다.
다음과 같습니다 :

징집병_chdir 0;

상대적인, 최상위 상대, 과 순수한 파일 이름

Build 명령에 지정된 파일 이름이 다음과 관련되어 있음을 알 수 있습니다.
호출되는 스크립트의 위치입니다. 이는 일반적으로 다른 파일 이름에도 해당됩니다.
다른 명령에 대한 인수도 포함됩니다. 여기서는 다음과 같이 언급할 수도 있습니다.
해시 표시 "#"이 있는 파일 이름이면 해당 파일은 최상위 항목을 기준으로 해석됩니다.
레벨 디렉토리(여기서 건설하다 파일이 상주합니다). 그리고 당연히 시작하면
``/''가 있으면 절대 경로 이름으로 간주됩니다. 이는 시스템에서도 마찬가지입니다.
절대 경로의 이름을 지정할 때 슬래시 대신 백슬래시를 사용합니다.

사용 모듈 in 빌드 스크립트

모듈을 각각에 끌어올 수 있습니다. 징집 일반적인 Perl `use' 또는 `require'를 사용하는 파일
진술 :

영어를 사용하다;
My::모듈이 필요합니다.

각 '사용' 또는 '요구'는 해당 항목에만 영향을 미칩니다. 징집 나타나는 파일입니다. 사용하려면
여러 개의 모듈 징집 파일의 경우 각 파일에 'use' 또는 'require' 문을 넣어야 합니다.
모듈이 필요한 것.

범위 of 변수

최상위 건설하다 파일 및 모든 징집 파일은 공통적이고 별도의 Perl에서 시작됩니다.
패키지. 단점 패키지의 기호 테이블을 제어하여
다음을 제외하고 각 스크립트는 비어 있습니다. 건설하다 명령줄의 일부를 가져오는 파일
인수. 따라서 설정되거나 사용되는 모든 변수는 스크립트에 의해 설정됩니다.
자체--외부 스크립트에 의한 것이 아닙니다.

변수는 명시적으로 가능합니다. 수입 상위 스크립트의 스크립트로. 가져오려면
변수였을 겁니다. 수출 부모에 의해 초기화되었습니다(그렇지 않으면 오류
일어날 것이다).

XNUMXD덴탈의 수출 명령

'내보내기' 명령은 다음 예와 같이 사용됩니다:

$env = 새로운 단점();
$INCLUDE = "#내보내기/포함";
$LIB = "#내보내기/lib";
qw 내보내기( env INCLUDE LIB );
qw( util/Conscript ) 빌드;

'내보내기' 목록에 언급된 단순 변수의 값은 흩어집니다.
후속 `Build' 명령에 의해. '내보내기' 명령은 Perl만 내보냅니다. 스칼라
변수, 즉 이름이 '$'로 시작하는 변수입니다. 기타 변수, 객체 등
참조로 내보낼 수 있지만 모든 스크립트는 동일한 개체를 참조합니다.
객체는 보조 스크립트와 원본에 의해 읽기 전용으로 간주되어야 합니다.
스크립트를 내보내는 중입니다. 그러나 내보낸 스칼라에 새 값을 할당하는 것은 허용됩니다.
변수--참조된 기본 변수는 변경되지 않습니다. 이 순서는
예를 들면 괜찮습니다.

$env = 새로운 단점();
qw 내보내기( env INCLUDE LIB );
qw( util/Conscript ) 빌드;
$env = new cons(CFLAGS => '-O');
qw 구축(기타/징집);

변수가 `Export' 명령 이전에 설정되었는지 이후에 설정되었는지는 중요하지 않습니다. 그만큼
중요한 것은 'Build' 명령이 실행되는 시점의 변수 값입니다.
이것이 흩어지는 것입니다. 그런데 이후의 '내보내기' 명령은 모두
첫 번째 항목을 무효화합니다. 각 항목에서 내보내려는 모든 변수를 언급해야 합니다.
'내보내기' 명령.

XNUMXD덴탈의 수입 명령

'내보내기' 명령으로 내보낸 변수는 다음을 통해 보조 스크립트로 가져올 수 있습니다.
'가져오기' 명령. 보조 스크립트는 항상 변수를 직접 가져옵니다.
우수한 스크립트. 다음 예를 고려하십시오.

qw 가져오기( env INCLUDE );

이는 상위 스크립트가 `$env'와 `$INCLUDE'를 모두 내보낸 경우에만 적법합니다. 또한 반드시
각 변수에 값을 지정했습니다. 보조 스크립트는 다음과 같이 해도 괜찮습니다.
내보낸 변수의 하위 집합을 가져옵니다(이 예에서는 '$LIB',
이전 예는 가져오지 않습니다).

가져온 모든 변수는 자동으로 다시 내보내지므로 순서는 다음과 같습니다.

qw 가져오기( env INCLUDE );
qw 구축(under-me/Conscript);

보조 파일에 `$env'와 `$INCLUDE'를 모두 제공합니다. `$env'만 사용하려는 경우
내보내면 다음으로 충분합니다.

qw 가져오기( env INCLUDE );
qw 내보내기( env );
qw 구축(under-me/Conscript);

말할 필요도 없이 변수는 'Build'를 호출하기 전에 로컬로 수정될 수 있습니다.
보조 스크립트.

짓다 스크립트 평가 주문

빌드 스크립트의 순서에 대한 유일한 제약은 우수한 스크립트가
열등한 스크립트보다 먼저 평가됩니다. 최상위 수준 건설하다 예를 들어 파일은 다음과 같습니다.
먼저 평가한 다음 하위 스크립트를 평가합니다. 이것이 당신이 정말로 알아야 할 전부입니다
순서는 일반적으로 중요하지 않기 때문에 평가 순서에 대해 설명합니다. 다음을 고려하세요
'빌드' 명령:

빌드 qw(
드라이버/디스플레이/징병
드라이버/마우스/징병
파서/징집병
공익사업/징집병
);

우리는 스크립트 이름을 알파벳순으로 배치하기로 결정했습니다. 왜냐하면 이것이 가장 중요하기 때문입니다.
유지 관리 목적으로 편리합니다. 순서를 바꿔도 별 차이는 없습니다
짓다.

A 모델 for 공유 파일

일부 간편한 설치 규칙

복잡한 소프트웨어 시스템에서는 빌드 제품을 공유하는 방법이 필요합니다.
확립된. 우리는 구현하기 쉬운 간단한 규칙 세트를 제안합니다.
단점이지만 매우 효과적입니다.

기본 규칙은 서로 공유해야 하는 모든 빌드 제품을 요구하는 것입니다.
디렉터리는 중간 디렉터리를 통해 공유됩니다. 우리는 일반적으로 이렇게 불렀습니다.
수출, 그리고 C 환경에서는 이 디렉토리의 일반적인 하위 디렉토리를 제공합니다.
등 포함, lib, 큰 상자등

이 디렉토리는 최상위 레벨에 의해 정의됩니다. 건설하다 파일. 간단한 건설하다 ~을위한 파일
a 안녕하세요 세계! 여러 디렉터리를 사용하여 구성된 애플리케이션은 다음과 같습니다.

# Hello, World! 파일을 구성합니다.

# 우리가 공유하는 모든 제품을 어디에 두나요?
$EXPORT = '#내보내기';

qw 내보내기(CONS INCLUDE LIB BIN);

# 제품 공유를 위한 표준 디렉토리.
$INCLUDE = "$EXPORT/포함";
$LIB = "$EXPORT/lib";
$BIN = "$EXPORT/빈";

# 표준 구축 환경.
$CONS = 새로운 단점(
CPPPATH => $INCLUDE, # C 컴파일 경로 포함
LIBPATH => $LIB, # 프로그램 연결을 위한 라이브러리 경로
LIBS => '-lworld', # 표준 라이브러리 목록
);

빌드 qw(
안녕하세요/징집병
세계/징집병
);

XNUMXD덴탈의 세계 디렉토리의 징집 파일은 다음과 같습니다.

# 디렉토리 세계를 위한 징집 파일
qw 가져오기(CONS INCLUDE LIB);

# 이 디렉토리의 제품을 설치합니다.
$CONS $LIB, 'libworld.a'를 설치합니다.
$CONS $INCLUDE, 'world.h'를 설치합니다.

# 내부 제품
라이브러리 $CONS 'libworld.a', 'world.c';

그리고 안녕하세요 디렉토리의 징집 파일은 다음과 같습니다.

# hello 디렉토리를 위한 징집 파일
qw 가져오기(CONS BIN);

# 수출제품
$CONS $BIN, 'hello'를 설치합니다.

# 내부 제품
프로그램 $CONS 'hello', 'hello.c';

건설하려면 안녕하세요 세계! 이 디렉토리 구조로 프로그램을 실행하려면 최상위 레벨로 이동하세요.
디렉토리를 선택하고 적절한 인수를 사용하여 `cons'를 호출합니다. 다음 예에서는
Cons에게 디렉토리를 구축하라고 지시하세요 수출. 디렉터리를 구축하기 위해 Cons는 모든 디렉터리를 재귀적으로 구축합니다.
해당 디렉토리 내의 알려진 제품(물론 재구축이 필요한 경우에만). 다음 중 하나라도 있다면
해당 제품은 다른 디렉토리의 다른 제품에 의존하므로 해당 제품이 구축됩니다.
도.

% 단점 수출
world/world.h를 import/include/world.h로 설치합니다.
cc -Iexport/include -c hello/hello.c -o hello/hello.o
cc -I내보내기/포함 -c world/world.c -o world/world.o
ar 세계/libworld.a 세계/world.o
ar: world/libworld.a 생성
ranlib 세계/libworld.a
world/libworld.a를 import/lib/libworld.a로 설치합니다.
cc -o 안녕하세요/안녕하세요 안녕하세요/hello.o -Lexport/lib -lworld
hello/hello를 import/bin/hello로 설치합니다.

깨끗한, 이해할 수 있는, 위치 독립적 스크립트

두 가지를 참고하시면 됩니다 징집 파일은 매우 깨끗하고 정확합니다. 그들은 단순히
디렉토리의 제품과 해당 제품을 구축하는 방법을 지정합니다. 빌드 지침
최소한입니다. 사용할 구성 환경, 제품 이름,
그리고 입력의 이름입니다. 또한 스크립트는 위치 독립적이라는 점에 유의하십시오.
소스 트리를 재구성하고 싶다면 자유롭게 그렇게 할 수 있습니다.
건설하다 파일(이 예에서는)의 새 위치를 지정합니다. 징집 파일. 그만큼
내보내기 트리를 사용하면 이 목표가 쉬워집니다.

또한 Cons가 귀하를 위해 작은 세부 사항을 어떻게 처리하는지 참고하십시오. 모든 수출 디렉토리,
예를 들어 자동으로 만들어졌습니다. 그리고 설치된 파일은 실제로
공간과 시간을 절약하기 위해 각각의 내보내기 디렉토리를 사용합니다. 세부 사항에 대한 이러한 관심은
상당한 작업이 필요하며 간단하고 유지 관리 가능한 스크립트를 더욱 쉽게 생성할 수 있습니다.

분리 과 빌드 나무

빌드에서 파생된 파일을 빌드 파일과 완전히 분리하여 유지하는 것이 바람직한 경우가 많습니다.
소스 파일. 이렇게 하면 소스 파일이 무엇인지 추적하는 것이 훨씬 더 쉬워집니다.
또한 처리하기가 더 간단해집니다. 다른 빌드, 특히 변형 빌드를 원하는 경우
공존하기 위해.

분리 빌드 과 디렉토리 사용 전에, (링크) 명령

Cons는 이러한 모든 요구 사항을 처리하는 간단한 메커니즘을 제공합니다. '링크'
다음 예와 같이 명령이 호출됩니다.

링크 '빌드' => 'src';

지정된 디렉토리는 지정된 소스 디렉토리에 "링크"됩니다. 가정해보자
소스 디렉토리를 설정하고, SRC, 하위 디렉토리 포함 세계 과 안녕하세요 그 아래에는,
이전 예에서와 같이. 그런 다음 원래 빌드 라인을 대체할 수 있습니다.
다음 :

빌드 qw(
빌드/세계/징집병
빌드/안녕하세요/징집병
);

다음을 치료한다는 점에 유의하세요. 징집 파일이 빌드 디렉터리에 있는 것처럼 보입니다. 이제 만약에
이전과 동일한 명령을 입력하면 다음과 같은 결과가 나타납니다.

% 단점 수출
build/world/world.h를 내보내기/include/world.h로 설치합니다.
cc -Iexport/include -c 빌드/hello/hello.c -o 빌드/hello/hello.o
cc -Iexport/include -c 빌드/world/world.c -o 빌드/world/world.o
ar r 빌드/세계/libworld.a 빌드/세계/세계.o
ar: build/world/libworld.a 생성
ranlib 빌드/세계/libworld.a
build/world/libworld.a를 import/lib/libworld.a로 설치합니다.
cc -o 빌드/hello/hello 빌드/hello/hello.o -Lexport/lib -lworld
build/hello/hello를 내보내기/bin/hello로 설치합니다.

다시 한번 말씀드리지만, Cons가 귀하를 위해 세부 사항을 처리해 드렸습니다. 특히, 당신은 모두가
빌드는 빌드 디렉터리의 소스 파일과 개체 파일을 사용하여 수행됩니다. 을 위한
예, 빌드/세계/world.o 에서 컴파일됩니다 빌드/세계/world.c및
내보내기/포함/world.h 에서 설치됩니다 빌드/세계/world.h. 이는 대부분의 경우에 수행됩니다.
각 소스에서 필요한 파일을 연결하는 "하드"라는 간단한 방법으로 시스템을
디렉토리를 적절한 빌드 디렉토리에 넣습니다.

링크는 소스 디렉토리에 무엇을 하든 Cons에 의해 올바르게 유지됩니다.
소스 파일을 수정하는 경우 편집자는 이 작업을 ``제자리''로 수행하거나 이름을 바꿀 수 있습니다.
먼저 새 파일을 만듭니다. 후자의 경우 모든 하드 링크가 손실됩니다. 단점은
다음에 소스 파일이 필요할 때 이 조건을 감지하고 다시 연결합니다.
적절하게.

그건 그렇고, 당신도 알게 될 것입니다 아니 기본에 대한 변경이 필요했습니다. 징집
파일. 그리고 다음 섹션에서 살펴보겠지만 더 나아갈 수도 있습니다.

변형 빌드

안녕하세요 세계! for 바나나 과 복숭아 운영 체제의

변형 빌드에는 또 다른 간단한 확장이 필요합니다. 예를 들어보자
baNaNa 및 peAcH 운영 체제 모두에 대한 빌드를 허용하기 위한 요구 사항입니다. 이 경우,
특정 시스템에 액세스하기 위해 NFS와 같은 분산 파일 시스템을 사용하고 있습니다.
특정 호출을 위해 시스템 중 하나만 컴파일하면 됩니다.
'단점'. 여기에 우리가 설정할 수 있는 한 가지 방법이 있습니다. 건설하다 우리를 위한 파일 안녕하세요 세계!
응용 프로그램 :

# Hello, World! 파일을 구성합니다.

$OS = $ARG{OS}가 아니면 die qq(OS를 지정해야 함);
die qq(OS는 "peach" 또는 "banana"여야 함)
if $OS ne "복숭아" && $OS ne "바나나";

# 우리가 공유하는 모든 제품을 어디에 두나요?
$EXPORT = "#수출/$OS";

qw 내보내기(CONS INCLUDE LIB BIN);

# 제품 공유를 위한 표준 디렉토리.
$INCLUDE = "$EXPORT/포함";
$LIB = "$EXPORT/lib";
$BIN = "$EXPORT/빈";

# 표준 구축 환경.
$CONS = 새로운 단점(
CPPPATH => $INCLUDE, # C 컴파일 경로 포함
LIBPATH => $LIB, # 프로그램 연결을 위한 라이브러리 경로
LIBS => '-lworld', # 표준 라이브러리 목록
);

# $BUILD는 모든 것을 파생시키는 곳입니다.
$BUILD = "#빌드/$OS";

# $BUILD의 소스 파일이 어디에 있는지 친구들에게 알려주세요.
링크 $BUILD => 'src';

짓다 (
"$BUILD/안녕하세요/징집",
"$BUILD/세계/징집병",
);

이제 peAcH 시스템에 로그인하면 다음을 구축할 수 있습니다. 안녕하세요 세계! 그것에 대한 신청
플랫폼:

% 단점 수출 OS = 복숭아
build/peach/world/world.h를 내보내기/peach/include/world.h로 설치합니다.
cc -Iexport/peach/include -c 빌드/peach/hello/hello.c -o 빌드/peach/hello/hello.o
cc -Iexport/peach/include -c 빌드/peach/world/world.c -o 빌드/peach/world/world.o
ar r 빌드/복숭아/세계/libworld.a 빌드/복숭아/세계/세계.o
ar: build/peach/world/libworld.a 생성 중
ranlib 빌드/peach/world/libworld.a
build/peach/world/libworld.a를 import/peach/lib/libworld.a로 설치합니다.
cc -o 빌드/peach/hello/hello 빌드/peach/hello/hello.o -Lexport/peach/lib -lworld
build/peach/hello/hello를 내보내기/peach/bin/hello로 설치합니다.

변화 on a 테마

이 모델의 다른 변형도 가능합니다. 예를 들어, 당신은 당신이 원하는 것을 결정할 수 있습니다
포함 파일을 플랫폼 종속 파일과 플랫폼 독립적 파일로 분리합니다.
이 경우 플랫폼에 따라 `$INCLUDE'에 대한 대안을 정의해야 합니다.
파일. 최대 징집 순전히 플랫폼 독립적인 포함 파일을 생성하는 파일은
변경할 필요는 없습니다.

디버깅이나 프로파일링을 통해 전체 시스템을 컴파일할 수도 있습니다.
예를 들어 활성화됩니다. 다음과 같은 적절한 명령줄 옵션을 사용하여 이 작업을 수행할 수 있습니다.
'디버그=켜짐'. 그런 다음 이는 적절한 플랫폼별 언어로 변환됩니다.
디버깅을 활성화하기 위한 요구 사항(여기에는 최적화 끄기가 포함될 수 있습니다.
예). 선택적으로 이러한 다양한 유형의 시스템에 대한 이름 공간을 변경할 수 있습니다.
하지만 다음 섹션에서 살펴보겠지만 그렇지 않습니다. 필수 이렇게 하려면 Cons가 예쁘기 때문에
옵션을 변경할 때 물건을 다시 만드는 것이 현명합니다.

서명

MD5 cryptographic 서명

Cons가 파생 파일을 생성할 때마다 서명 해당 파일에 대해. 서명
디렉토리당 하나씩 별도의 파일에 저장됩니다. 이전 예제를 컴파일한 후,
전에, .따로 두다 에 파일을 빌드/복숭아/세계 디렉토리는 다음과 같습니다.

world.o:834179303 23844c0b102ecdc0b4548d1cd1cbd8c6
libworld.a:834179304 9bf6587fa06ec49d864811a105222c00

첫 번째 숫자는 타임스탬프입니다. UNIX 시스템의 경우 이는 일반적으로
1년 1970월 5일 이후 초입니다. 두 번째 값은 MDXNUMX 체크섬입니다. 그만큼 보내실 내용 요람
암호알고리즘 입력 문자열이 주어지면 강력한 암호화를 계산하는 알고리즘입니다.
해당 문자열에 대한 서명입니다. MD5 체크섬은 .따로 두다 파일은 사실상
지정된 파일에 대한 모든 종속성 정보를 요약합니다. 예를 들어,
월드.오 파일에는 최소한 다음이 포함됩니다. world.c 파일 및 헤더 파일도 포함됩니다.
직접 또는 간접적으로 포함되어 있음을 알고 있습니다. world.c. 뿐만 아니라
생성하는 데 사용된 실제 명령줄 월드.오 또한 계산에 반영됩니다.
서명. 비슷하게, libworld.a 모든 것을 "포함"하는 서명을 얻습니다.
구성 요소의 서명(따라서 전이적으로 그들의
구성 요소) 및 파일을 생성한 명령줄도 포함됩니다.

파생되지 않은 파일의 서명은 기본적으로 현재 서명을 사용하여 계산됩니다.
파일 수정 시간 및 파일 항목 이름(해당되는 경우 제외)
current .따로 두다 해당 파일에 대한 항목이며, 이 경우 해당 서명이 사용됩니다).

파생된 파일이 특정 파일에 종속될 필요는 없습니다. 건설하다 or
징집 파일--이 파일의 변경 사항이 문제의 파일에 영향을 미치는 경우 다음과 같습니다.
명령줄의 관련 부분이 자동으로 서명에 반영됩니다.
서명에 포함됩니다. 관련되지 않은 변경 사항은 적용되지 않습니다.

Cons가 특정 파일을 파생할지 여부를 고려할 때 먼저 다음을 계산합니다.
파일의 예상 서명. 그런 다음 파일의 마지막 수정 시간을 다음과 비교합니다.
에 기록된 시간 .따로 두다 항목(존재하는 경우) 이 시간이 일치하면
에 저장된 서명 .따로 두다 파일은 정확한 것으로 간주됩니다. 파일이 이전 파일인 경우
서명이 예상되는 새 서명과 일치하지 않으면 파일을 다시 파생해야 합니다.

종속 파일에 대한 내용이 변경될 때마다 파일이 다시 파생됩니다. ~ 안에
특히, 주의하세요 어떤 종속 항목의 수정 시간으로 변경(앞으로 또는
시간을 거꾸로) 파생된 파일을 강제로 다시 컴파일합니다.

이러한 서명을 사용하는 것은 매우 간단하고 효율적이며 효과적인 방법입니다.
시스템의 재현성을 극적으로 향상시킵니다.

간단한 예를 통해 이를 보여드리겠습니다.

# 간단하게 "Hello, World!" 파일 구성
$CFLAGS = $ARG{DEBUG} eq 'on'인 경우 '-g';
$CONS = 새로운 단점(CFLAGS => $CFLAGS);
프로그램 $CONS 'hello', 'hello.c';

Cons가 적절한 시점에 어떻게 재컴파일되는지 확인하세요.

단점 % 안녕하세요
cc -c 안녕하세요.c -o 안녕하세요.o
cc -o 안녕하세요 안녕하세요.o
단점 % 안녕하세요
단점: "hello"는 최신입니다.
% 단점 DEBUG=안녕하세요
cc -g -c 안녕하세요.c -o 안녕하세요.o
cc -o 안녕하세요 안녕하세요.o
% 단점 DEBUG=안녕하세요
단점: "hello"는 최신입니다.
단점 % 안녕하세요
cc -c 안녕하세요.c -o 안녕하세요.o
cc -o 안녕하세요 안녕하세요.o

암호 저장소

많은 소프트웨어 개발 조직에는 하나 이상의 중앙 저장소 디렉터리가 있습니다.
하나 이상의 프로젝트에 대한 현재 소스 코드와 파생된 소스 코드가 포함된 트리
개체 파일, 라이브러리 및 실행 파일. 불필요한 재컴파일을 줄이기 위해,
개발 소프트웨어를 구축하기 위해 저장소의 파일을 사용하는 것이 유용합니다.
물론 로컬 빌드 트리에는 최신 종속성 파일이 없습니다.

저장소

Cons는 검색할 코드 저장소 목록을 지정하는 메커니즘을 제공합니다.
로컬 빌드 디렉터리 트리에서 찾을 수 없는 소스 파일과 파생 파일에 대해 순서대로.

다음 줄은 건설하다 파일은 Cons에게 아래를 먼저 보라고 지시합니다.
/usr/실험/저장소 디렉토리를 선택한 다음 그 아래에 /usr/제품/저장소 예배 규칙서:

저장소 qw(
/usr/실험/저장소
/usr/제품/저장소
);

지정된 저장소 디렉토리에는 소스 파일, 파생 파일(객체,
라이브러리 및 실행 파일) 또는 둘 다. 아래에 로컬 파일(소스 또는 파생)이 없는 경우
Cons가 실행되는 디렉터리, 같은 이름의 파일의 첫 번째 복사본이 발견됨
저장소 디렉토리 아래에서는 로컬 파생 파일을 빌드하는 데 사용됩니다.

Cons는 하나의 저장소 디렉터리 전체 목록을 유지 관리합니다. 단점은
현재 디렉토리와 존재하지 않는 디렉토리를 목록에서 선택합니다.

발견 전에, 건설하다 파일 in a 저장소

단점도 다음을 검색합니다. 건설하다 과 징집 저장소 트리의 파일.
그러나 이는 닭고기와 달걀의 상황으로 이어집니다. 저장소 트리를 어떻게 보나요?
A에 대한 건설하다 다음과 같은 경우 파일을 제출하세요. 건설하다 파일은 저장소가 어디에 있는지 알려줍니다. 얻으려면
이 경우 명령줄에서 `-R' 옵션을 통해 저장소를 지정할 수 있습니다:

% 단점 -R /usr/experiment/repository -R /usr/product/repository .

다음에 지정된 모든 저장소 디렉토리 건설하다 or 징집 파일이 추가됩니다
명령줄 `-R' 옵션으로 지정된 저장소 디렉터리로 이동합니다.

저장소 파일

소스 코드(포함 징집 파일)의 라이브러리 버전에 대한 안녕하세요
세계! C 응용 프로그램은 저장소에 있습니다(파생 파일 없음). Cons는 다음을 사용합니다.
로컬 객체 파일과 실행 파일을 생성하기 위한 저장소 소스 파일:

% 단점 -R /usr/src_only/repository 안녕하세요
gcc -c /usr/src_only/repository/hello.c -o 안녕하세요.o
gcc -c /usr/src_only/repository/world.c -o world.o
ar r libworld.a world.o
ar: libworld.a 생성
ranlib libworld.a
gcc -o 안녕하세요 hello.o libworld.a

로컬 소스 파일을 생성하면 Cons가 적절한 파생 파일을 다시 작성하거나
파일 :

% 피코 월드.c
[편집하다]
% 단점 -R /usr/src_only/repository 안녕하세요
gcc -c 세계.c -o 세계.o
ar r libworld.a world.o
ar: libworld.a 생성
ranlib libworld.a
gcc -o 안녕하세요 hello.o libworld.a

그리고 로컬 소스 파일을 제거하면 Cons가 파생된 파일을 다시 빌드하는 것으로 되돌아갑니다.
저장소 소스의 파일:

% rm 세계.c
% 단점 -R /usr/src_only/repository 안녕하세요
gcc -c /usr/src_only/repository/world.c -o world.o
ar r libworld.a world.o
ar: libworld.a 생성
ranlib libworld.a
gcc -o 안녕하세요 hello.o libworld.a

저장소 유래 된 파일

저장소 트리에 파생 파일(일반적으로 개체 파일, 라이브러리 또는
실행 파일) Cons는 일반적인 서명 계산을 수행하여
저장소 파일이 최신이거나 파생된 파일을 로컬로 빌드해야 합니다. 이는 다음을 의미합니다.
올바른 서명 계산을 보장하려면 저장소 트리에 다음 항목도 포함되어야 합니다.
.따로 두다 파생된 파일을 생성할 때 Cons가 생성한 파일입니다.

이는 일반적으로 저장소(또는
또는 빌드 디렉터리에서 결과를 저장소에 복사합니다.

% cd /usr/all/저장소
단점 % 안녕하세요
gcc -c 안녕하세요.c -o 안녕하세요.o
gcc -c 세계.c -o 세계.o
ar r libworld.a world.o
ar: libworld.a 생성
ranlib libworld.a
gcc -o 안녕하세요 hello.o libworld.a

(이것은 안전합니다. 건설하다 파일에는 다음이 나열됩니다. /usr/모두/저장소 디렉토리
Cons가 저장소에서 현재 디렉토리를 제거하기 때문에 `Repository' 명령
목록.)

이제 우리 자신의 애플리케이션 사본을 만들고 싶다면 안녕하세요.c 파일, 우리에게 필요한 것은
하나의 필요한 소스 파일을 생성하고 `-R' 옵션을 사용하여 Cons가 다른 파일을 사용하도록 합니다.
저장소의 파일:

% mkdir $HOME/빌드1
% cd $HOME/build1
% 에드 hello.c
[편집하다]
% 단점 -R /usr/all/repository 안녕하세요
gcc -c 안녕하세요.c -o 안녕하세요.o
gcc -o hello hello.o /usr/all/repository/libworld.a

Cons는 로컬을 다시 생성하는 데 신경을 쓰지 않았습니다. libworld.a 라이브러리(또는
월드.오 모듈) 대신 저장소에서 이미 컴파일된 버전을 사용합니다.

Cons가 넣는 MD5 서명은 .따로 두다 파일에는 다음에 대한 타임스탬프가 포함되어 있습니다.
파생된 파일의 경우 서명 타임스탬프는 서명의 파일 타임스탬프와 일치해야 합니다.
유효한 것으로 간주됩니다.

일부 소프트웨어 시스템은 저장소 파일의 타임스탬프를 변경할 수 있습니다(파일을 복사하여,
예) 이 경우 Cons는 기본적으로 저장소 서명이 유효하지 않다고 가정합니다.
불필요하게 파일을 다시 빌드합니다. 이 동작은 다음을 지정하여 변경할 수 있습니다.

Repository_Sig_Times_OK 0;

이는 Cons가 서명이 유효한지 결정할 때 타임스탬프를 무시하도록 지시합니다. (메모
이 온전성 검사를 피한다는 것은 저장소에 대한 적절한 제어가 있어야 함을 의미합니다.
트리를 업데이트하지 않고는 파생된 파일을 수정할 수 없도록 보장합니다. .따로 두다
서명.)

지방의 사본들 of 파일

저장소 트리에 빌드의 전체 결과가 포함되어 있고 다음에서 빌드하려고 하면
로컬 트리에 파일이 없는 저장소는 다소 놀라운 일입니다.
발생:

% mkdir $HOME/빌드2
% cd $HOME/build2
% 단점 -R /usr/all/repository 안녕하세요
단점: "hello"는 최신입니다.

Cons는 왜 그렇게 말합니까? 안녕하세요 프로그램이 없을 때 최신 상태입니다. 안녕하세요 ~에있는 프로그램
로컬 빌드 디렉토리? 저장소(로컬 디렉토리가 아님)에
최신의 안녕하세요 프로그램을 실행하고 Cons는 아무것도 수행할 필요가 없다고 올바르게 결정합니다.
이 파일의 최신 복사본을 다시 작성하십시오.

그러나 로컬 사본을 확보하는 것이 적절한 경우가 많습니다.
파일은 항상 존재합니다. 예를 들어, 패키징 또는 테스트 스크립트는 다음을 가정할 수 있습니다.
생성된 파일이 로컬에 존재합니다. 이러한 보조 스크립트가
저장소 디렉토리에 'Local' 명령을 추가할 수 있습니다. 건설하다 or 징집 에 파일을
특정 파일이 로컬 빌드 디렉터리에 나타나도록 지정합니다.

지역 qw(
안녕하세요
);

그런 다음 동일한 명령을 다시 실행하면 Cons는 다음에서 프로그램의 로컬 복사본을 만듭니다.
저장소 복사본(그렇게 하고 있음을 알려줌):

% 단점 -R /usr/all/repository 안녕하세요
/usr/all/repository/hello의 hello 로컬 복사본
단점: "hello"는 최신입니다.

로컬 복사본을 만드는 행위는 "빌드"로 간주되지 않으므로 주의하세요.
안녕하세요 파일, Cons는 여전히 최신 상태라고 보고합니다.

로컬 복사본을 만드는 것은 다음 위치에 설치되는 파일에 가장 유용합니다.
`Install' 명령을 통해 중간 디렉토리(다른 디렉토리와 공유하기 위한).
`Local' 명령과 함께 파일에 대한 `Install' 명령을 동반하는 것은 다음과 같습니다.
일반적으로 Cons는 두 가지 작업을 모두 수행하는 편리한 방법으로 'Install_Local' 명령을 제공합니다.

Install_Local $env, '#export', 'hello';

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

$env '#export', 'hello'를 설치하세요.
로컬 '#export/hello';

`Local' 및 `Install_Local' 명령 모두 로컬을 업데이트합니다. .따로 두다 로 파일
적절한 파일 서명을 사용하여 향후 빌드가 올바르게 수행되도록 합니다.

저장소 의존 분석

내장된 검색 기능으로 인해 Cons는 지정된 저장소 트리에서 포함된 항목을 검색합니다.
.h 파일. 그러나 컴파일러가 저장소 트리에 대해서도 알지 않는 한,
찾을 수 없다 .h 저장소에만 존재하는 파일입니다. 예를 들어, 안녕하세요.c
파일에는 다음이 포함됩니다. 안녕하세요.h 현재 디렉터리에 있는 파일:

% 단점 -R /usr/all/repository 안녕하세요
gcc -c /usr/all/repository/hello.c -o 안녕하세요.o
/usr/all/repository/hello.c:1: hello.h: 해당 파일이나 디렉터리가 없습니다.

이 문제를 해결하려면 건설 환경의 방식에 몇 가지 요구 사항이 필요합니다.
정의된 C `#include' 전처리기 지시문이 파일을 포함하는 데 사용되는 방식에 대해 설명합니다.

저장소 트리에 대해 컴파일러에 알리기 위해 Cons는 적절한 `-I'를 추가합니다.
컴파일 명령에 플래그를 지정합니다. 이는 'CPPPATH' 변수가
구성 환경은 검색할 모든 하위 디렉터리를 명시적으로 지정해야 합니다.
현재 디렉터리를 포함하여 포함된 파일의 경우. 결과적으로 위의 문제를 해결할 수 있습니다.
예를 들어 환경 생성을 변경하여 건설하다 파일은 다음과 같습니다.

$env = 새로운 단점(
CC => 'gcc',
CPPPATH => '.',
LIBS => 'libworld.a',
);

`CPPPATH' 변수의 정의로 인해 우리가
명령:

% 단점 -R /usr/all/repository 안녕하세요
gcc -c -I. -I/usr/all/repository /usr/all/repository/hello.c -o hello.o
gcc -o hello hello.o /usr/all/repository/libworld.a

C 전처리기의 경우 `-I' 플래그의 순서는 동일한 저장소를 복제합니다.
Cons가 자체 종속성 분석을 위해 사용하는 디렉터리 검색 경로입니다. 만일 거기에
여러 저장소와 여러 'CPPPATH' 디렉터리, Cons는 저장소를 추가합니다.
디렉토리를 각 `CPPPATH' 디렉토리의 시작 부분으로 이동하여 숫자를 빠르게 증가시킵니다.
-I' 플래그. 극단적인 예로, 건설하다 다음을 포함하는 파일:

저장소 qw(
/u1
/u2
);

$env = 새로운 단점(
CPPPATH => 'a:b:c',
);

다음과 같은 컴파일 명령이 생성됩니다.

cc -Ia -I/u1/a -I/u2/a -Ib -I/u1/b -I/u2/b -Ic -I/u1/c -I/u2/c -c hello.c -o 안녕하세요.o

Cons는 컴파일러의 `-I' 플래그에 의존하여 순서를 전달하기 때문입니다.
저장소 디렉토리를 검색해야 하며, Cons의 저장소 디렉토리 처리는 다음과 같습니다.
C의 `#include' 지시문에 큰따옴표를 사용하는 것과 근본적으로 호환되지 않습니다.
소스 코드:

#include "file.h" /* 이와 같은 큰따옴표를 사용하지 마세요 */

이는 대부분의 C 전처리기가 그러한 지시문에 직면할 때 항상 먼저 처리하기 때문입니다.
소스 파일이 포함된 디렉터리를 검색합니다. 이는 정교한 '-나'를 약화시킨다.
Cons가 전처리기가 선호하는 검색을 따르도록 구성하는 옵션
통로.

결과적으로 Cons에서 저장소 트리를 사용할 때, 항상 포함된 항목에는 꺾쇠 괄호를 사용하세요.
파일 :

#포함하다 /* 대신 꺾쇠 괄호를 사용하세요 */

저장소_목록

Cons는 모든 저장소 디렉토리 목록을 반환하는 `Repository_List' 명령을 제공합니다.
현재 검색 순서대로. 이는 디버깅이나 더 복잡한 Perl 작업에 사용될 수 있습니다.
물건:

@list = 저장소_목록;
인쇄 Join(' ', @list), "\n";

저장소 상호 작용 과 other 단점 풍모

Cons의 저장소 트리 처리는 다른 Cons 기능과 올바르게 상호 작용합니다.
즉, 일반적으로 예상한 대로 작동합니다.

가장 주목할 만한 점은 저장소 트리가 '링크'와 정확하고 강력하게 상호 작용한다는 것입니다.
명령. 저장소 트리에는 버전 빌드를 위한 하나 이상의 하위 디렉터리가 포함될 수 있습니다.
소스 하위 디렉터리에 대한 '링크'를 통해 설정됩니다. 단점은 다음에서 파생된 파일을 검색합니다.
저장소 트리 아래의 적절한 빌드 하위 디렉터리.

태만 목표

지금까지 우리는 명시적인 빌드 대상을 사용하여 Cons를 호출하는 방법을 보여주었습니다.

단점 % 안녕하세요

일반적으로 Cons는 대상이 지정되지 않은 한 아무것도 빌드하지 않지만 '.'을 지정합니다.
(현재 디렉터리)는 모든 것을 빌드합니다:

% 단점 # 아무것도 빌드하지 않습니다

단점 %. # 최상위 디렉토리 아래에 모든 것을 빌드합니다.

모든 항목에 `Default' 메소드 추가 건설하다 or 징집 파일은 지정된 것을 추가합니다
대상을 기본 대상 목록으로 지정합니다. 단점은 없는 경우 이러한 기본값을 구축합니다.
명령줄에 지정된 대상. 따라서 최상위 수준에 다음 줄을 추가합니다.
건설하다 파일은 기본적으로 모든 것을 빌드하는 Make의 일반적인 동작을 모방합니다.

기본 '.';

다음은 안녕하세요 과 안녕 명령(명령어와 동일한 디렉토리에 있음)
건설하다 or 징집 파일)을 기본 목록으로:

기본 qw(
안녕하세요
안녕
);

`Default' 메소드는 기본 목록에 대상을 추가하기 위해 두 번 이상 사용될 수 있습니다.

선택적인 빌드

Cons는 주어진 빌드의 크기를 줄이는 두 가지 방법을 제공합니다. 첫 번째는 지정하는 것입니다.
명령줄에서 대상을 지정하고 두 번째는 빌드 트리를 정리하는 방법입니다. 잘
먼저 목표 사양을 고려하십시오.

선택적인 대상

make와 마찬가지로 Cons는 명령줄에서 "대상"을 지정할 수 있습니다. 단점 타겟
파일일 수도 있고 디렉터리일 수도 있습니다. 디렉토리가 지정되면 이는 간단히 말해서 다음과 같습니다.
Cons가 알고 있는 모든 파생 제품에 대한 손 표기법
디렉토리 이하. 예를 들어:

% 단점 build/hello/hello.o

빌드를 의미한다 안녕하세요. 그리고 그 모든 것 안녕하세요. 필요로 할 수도있다. 이것은 이전에 나온 것입니다.
의 버전 안녕하세요 세계! 프로그램 안녕하세요. 에 의존
내보내기/포함/world.h. 해당 파일이 최신이 아닌 경우(누군가가 수정했기 때문에)
소스/세계/world.h)이면 원격 디렉토리에 있더라도 다시 작성됩니다.
빌드/안녕하세요.

이 예에서 :

% 단점 빌드

모든 빌드 필요한 경우 디렉토리가 빌드됩니다. 다시 말하지만 이로 인해 더 많은 파일이 발생할 수 있습니다.
건설됩니다. 특히, 둘 다 내보내기/포함/world.h 과 내보내기/lib/libworld.a are
에 의해 요구되는 빌드/안녕하세요 디렉토리이므로 오래된 경우 빌드됩니다.

그렇다면 대신:

% 단점 수출

그런 다음 내보내기 디렉터리에 설치되어야 하는 파일만 다시 빌드됩니다.
필요하고 거기에 설치됩니다. `cons build'는 `cons build'라는 파일을 빌드할 수도 있다는 점에 유의하세요.
내보내기'는 빌드되지 않으며 그 반대도 마찬가지입니다.

아니 ``특별한'' 목표

단점을 사용하면 make 스타일의 ``특별한'' 타겟이 필요하지 않습니다. 단점이 있는 가장 간단한 아날로그
특수하게 사용하는 것입니다 수출 대신 디렉토리. 예를 들어 당신이
코드와 관련된 전체 단위 테스트 시리즈입니다. 테스트는
코드 근처의 소스 디렉토리. 그러나 일반적으로 이러한 테스트를 빌드하고 싶지는 않습니다.
한 가지 해결책은 테스트 생성을 위한 모든 빌드 지침을 제공한 다음
테스트를 트리의 별도 부분에 설치합니다. 최상위 레벨에 테스트를 설치하면
전화 번호부 테스트그런 다음 :

% 단점 테스트

모든 테스트를 구축할 것입니다.

% 단점 수출

시스템의 프로덕션 버전을 구축합니다(테스트는 아님).

% 단점 빌드

아마도 피해야 할 것입니다(불필요하게 테스트를 컴파일하기 때문입니다).

단일 테스트만 작성하려면 테스트 이름을 명시적으로 지정할 수 있습니다(
중 테스트 디렉토리 또는 빌드 예배 규칙서). 테스트를 집계할 수도 있습니다.
테스트 디렉토리 내의 편리한 계층 구조로 구성됩니다. 이 계층 구조는 필요하지 않습니다.
포함 계층 구조와 거의 동일한 방식으로 소스 계층 구조와 반드시 일치해야 합니다.
아마도 소스 계층과 일치하지 않을 것입니다(포함 계층이 더 이상일 가능성이 없음).
C 프로그램의 경우 두 수준 이상 깊이).

트리의 모든 것을 절대적으로 구축하려는 경우(선택한 옵션에 따라 다름)
선택) 다음을 사용할 수 있습니다.

단점 %.

이는 모든 트리를 중복적으로 탐색하므로 특별히 효율적이지 않습니다.
소스 트리를 포함합니다. 물론 소스 트리에는 빌드 가능한 객체가 있을 수 있습니다.
--일반적으로 별도의 빌드로 빌드하더라도 이 작업을 수행하는 것을 막을 수 있는 것은 없습니다.
나무.

짓다 전정

대상 선정과 연계하여, 빌드 전정 범위를 줄이는 데 사용할 수 있습니다.
짓다. 이전 peAcH 및 baNaNa 예시에서 우리는 이미 스크립트 기반
빌드 가지치기를 사용하면 주어진 특정 작업에 대해 잠재적인 빌드의 절반만 사용할 수 있습니다.
'cons' 호출. 단점은 또한 편의상 다음과 같은 명령줄 규칙을 제공합니다.
당신이 지정할 수 있습니다 징집 파일은 실제로 '빌드'됩니다. 즉, 통합됩니다.
빌드 트리에 들어갑니다. 예를 들어:

% 단점 빌드 +세계

'+' 인수는 Perl 정규식을 도입합니다. 물론 이 내용은 다음에서 인용되어야 합니다.
표현식 내에 쉘 메타 문자가 있는 경우 쉘 레벨. 그만큼
표현식은 각각에 대해 일치됩니다. 징집 '빌드'에서 언급된 파일
명령문에 일치하는 이름을 가진 스크립트만 실제로 통합됩니다.
나무를 짓다. 이러한 인수는 여러 개가 허용되며, 이 경우 그 중 하나와 일치합니다.
스크립트를 포함시키는 데 충분합니다.

위의 예에서는 안녕하세요 Cons에는 아무 것도 없기 때문에 프로그램은 구축되지 않습니다.
대본에 대한 지식 안녕하세요/징집병. 그만큼 libworld.a 그러나 다음과 같은 경우에는 아카이브가 구축됩니다.
필요합니다.

명령줄을 통한 빌드 정리에는 몇 가지 용도가 있습니다. 아마도 가장 유용한 것
로컬 변경을 수행할 수 있는 능력이며, 다음에 대한 충분한 지식이 있어야 합니다.
이러한 변경으로 인해 속도를 높이기 위해 빌드 트리의 크기를 제한합니다.
재건축 시간. 빌드 정리의 두 번째 용도는 재컴파일을 적극적으로 방지하는 것입니다.
예를 들어 수정된 헤더 파일로 인해 다시 컴파일될 특정 파일.
헤더 파일의 변경 사항이 중요하지 않거나
테스트 목적으로 대부분의 트리에서 변경 사항을 안전하게 무시할 수 있습니다.
관점은 다음과 같은 이해와 함께 이러한 유형의 행동을 인정하는 것이 실용적이라는 것입니다.
다음 전체 빌드에서는 다시 빌드해야 하는 모든 항목이 변경됩니다. 동등한 것이 없습니다
파일을 영구적으로 최신 상태로 표시하려면 ``make touch'' 명령을 사용하세요. 그래서 어떤 위험도
빌드 정리로 인해 발생하는 문제가 완화됩니다. 릴리스 품질 작업을 위해서는 당연히 다음을 권장합니다.
빌드 정리를 사용하지 않습니다(통합 중에 사용해도 괜찮지만,
컴파일 확인 등을 위해 커밋하기 전에 제한되지 않은 빌드를 수행하십시오.
통합).

일시적인 재정의

단점은 빌드 측면을 재정의하기 위한 매우 간단한 메커니즘을 제공합니다. 본질은
하나 이상의 'Override' 명령을 포함하는 재정의 파일을 작성하고
`cons'를 실행할 때 명령줄에서 이를 지정하십시오:

수출에 대한 % 단점 -o

구축할 것이다 수출 재정의가 적용되는 모든 파생 파일이 있는 디렉터리
FBI 증오 범죄 보고서 위에 파일. `-o' 옵션을 생략하면 제거하는 데 필요한 모든 항목이 제거됩니다.
모든 재정의가 다시 작성됩니다.

재정의 환경 변수

대체 파일에는 두 가지 유형의 대체가 포함될 수 있습니다. 첫 번째는 들어오는 환경입니다.
변수. 이들은 일반적으로 다음을 통해 액세스할 수 있습니다. 건설하다 `%ENV' 해시의 파일
변하기 쉬운. 이는 재정의 파일에서 다음을 설정하여 간단하게 재정의할 수 있습니다.
`%ENV'의 적절한 요소(이것은 사용자 환경에서 재정의될 수도 있습니다.
물론이야).

XNUMXD덴탈의 재정의 명령

두 번째 유형의 재정의는 다음과 같은 `Override' 명령을 사용하여 수행됩니다.
이:

우세하다 , => , => , ...;

정규식 정규 표현식 후보인 모든 파생 파일과 일치됩니다.
빌드를 위해. 파생된 파일이 일치하면 변수/값 쌍이 사용됩니다.
파생된 파일과 연관된 구성 환경의 값을 재정의합니다.

다음과 같은 구성 환경이 있다고 가정해 보겠습니다.

$CONS = 새로운 단점(
COPT => '',
CDBG => '-g',
CFLAGS => '%COPT %CDBG',
);

그런 다음 재정의 파일이 있으면 위에 다음 명령이 포함되어 있습니다.

재정의 '\.o$', COPT => '-O', CDBG => '';

그러면 `-o over'를 사용한 `cons' 호출이 생성됩니다. .o 이 환경을 통한 파일은
`-O'를 사용하고 `-g'를 사용하지 않고 컴파일하도록 합니다. 물론 재정의는 다음과 같을 수 있습니다.
정규식을 적절하게 선택하면 단일 디렉터리로 제한됩니다.

Hello, World!의 원본 버전은 다음과 같습니다. 이 환경으로 구축된 프로그램입니다.
재정의가 적용되거나 제거되면 Cons는 적절한 부분을 다시 빌드합니다.

단점 % 안녕하세요
cc -g -c 안녕하세요.c -o 안녕하세요.o
cc -o 안녕하세요 안녕하세요.o
% 단점 -o 안녕하세요
cc -O -c 안녕하세요.c -o 안녕하세요.o
cc -o 안녕하세요 안녕하세요.o
% 단점 -o 안녕하세요
단점: "hello"는 최신입니다.
단점 % 안녕하세요
cc -g -c 안녕하세요.c -o 안녕하세요.o
cc -o 안녕하세요 안녕하세요.o

'재정의' 명령은 임시적이고 즉석적인 경우에만 사용하는 것이 중요합니다.
재정의는 플랫폼 독립적이지 않기 때문에 개발에 필요하며
왜냐하면 그들은 대본의 작동에 대한 친밀한 지식에 너무 많이 의존하기 때문입니다. 을 위한
그러나 임시 사용은 정확히 당신이 원하는 것입니다.

예를 들어 완전히 최적화된 환경을 생성하는 기능을 제공하는 것은 여전히 ​​​​유용합니다.
생산용 시스템 버전 - 건설하다 과 징집 파일. 이 방법
플랫폼에 최적화된 시스템을 맞춤화할 수 있습니다. 최적화 프로그램의 균형이 필요한 경우
만들어졌습니다(예를 들어 특정 파일은 전체 최적화로 컴파일되지 않을 수 있음).
이러한 내용은 후손을 위해 스크립트에 직접 기록될 수 있습니다.

더 보기 on 구조 환경

태만 구조 변수

우리는 a의 개념을 언급하고 사용했습니다. 구조 환경, 여러 번
이전 페이지. 이제 이것을 좀 더 구체적으로 만들 차례입니다. 다음과 함께
성명서:

$env = 새로운 단점();

새로운 기본 구성 환경에 대한 참조가 생성됩니다. 여기에는 숫자가 포함되어 있습니다.
구성 변수 및 일부 방법. 현재 작성 중인 기본 목록은 다음과 같습니다.
구성 변수는 다음과 같이 정의됩니다.

CC => 'cc',
CFLAGS => '',
CCCOM => '%CC %CFLAGS %_IFLAGS -c %< -o %>',
INCDIRPREFIX => '-나',
CXX => '%CC',
CXXFLAGS => '%CFLAGS',
CXXCOM => '%CXX %CXXFLAGS %_IFLAGS -c %< -o %>',
링크 => '%CXX',
LINKCOM => '%LINK %LDFLAGS -o %> %< %_LDIRS %LIBS',
LINKMODULECOM => '%LD -r -o %> %<',
LIBDIRPREFIX => '-L',
AR => '아르',
ARFLAGS => 'r',
ARCOM => "%AR %ARFLAGS %> %<\n%RANLIB %>",
RANLIB => '랜립',
그대로 => '대로',
ASFLAGS => '',
ASCOM => '%AS %ASFLAGS %< -o %>',
LD => 'ld',
LDFLAGS => '',
PREFLIB => 'lib',
SUFLIB => '.a',
SUFLIBS => '.so:.a',
SUFOBJ => '.o',
ENV => { '경로' => '/큰 상자:/ usr / bin' },

Win32 시스템(Windows NT)에서는 다음 구성 변수가 재정의됩니다.
기본값 :

CC => 'cl',
CFLAGS => '/nologo',
CCCOM => '%CC %CFLAGS %_IFLAGS /c %< /Fo%>',
CXXCOM => '%CXX %CXXFLAGS %_IFLAGS /c %< /Fo%>',
INCDIRPREFIX => '/나',
링크 => '링크',
LINKCOM => '%LINK %LDFLAGS /out:%> %< %_LDIRS %LIBS',
LINKMODULECOM => '%LD /r /o %> %<',
LIBDIRPREFIX => '/LIBPATH:',
AR => 'lib',
ARFLAGS => '/nologo',
ARCOM => "%AR %ARFLAGS /out:%> %<",
RANLIB => '',
LD => '링크',
LDFLAGS => '/nologo',
PREFLIB => '',
SUFEXE => '.exe',
SUFLIB => '.lib',
SUFLIBS => '.dll:.lib',
SUFOBJ => '.obj',

이러한 변수는 환경과 관련된 다양한 방법에 의해 사용됩니다.
특히 외부 명령을 궁극적으로 호출하는 모든 메서드는 이러한 명령을 대체합니다.
변수를 적절하게 최종 명령에 추가합니다. 예를 들어 `Objects' 메소드는
다수의 소스 파일을 생성하고 필요한 경우 해당 객체를 파생하도록 준비합니다.
파일. 예를 들어:

객체 $env 'foo.c', 'bar.c';

필요한 경우 이를 생산하도록 준비합니다. 푸.오 과 바오. 호출된 명령은 단순히
대체를 통해 필요한 적절한 외부 명령으로 확장되는 `%CCCOM'
각 객체를 구축합니다. 'Command'에서 대체 규칙을 더 자세히 살펴보겠습니다.
방법은 아래에 있습니다.

구성 변수는 다른 목적으로도 사용됩니다. 예를 들어 `CPPPATH'는
포함 디렉터리의 콜론으로 구분된 경로를 지정하는 데 사용됩니다. 이것들은 다음과 같은 목적으로 사용됩니다.
C 전처리기로 전달되며 C 파일 검색 기계에서도 사용됩니다.
C 컴파일과 관련된 종속성을 결정합니다. 다음으로 시작하는 변수
밑줄은 다양한 방법으로 생성되며 일반적으로 '내부'로 간주되어야 합니다.
변수. 예를 들어, 객체 생성을 요구하는 메서드가 호출될 때
C 소스에서는 `_IFLAGS' 변수가 생성됩니다. 이는 `-I' 스위치에 해당합니다.
`CPPPATH'에 의해 지정된 디렉토리를 나타내기 위해 C 컴파일러에 의해 요구됩니다.

특정 환경에서는 변수 값이 한 번 설정되고 그 다음에는
절대 재설정하지 않음(변수를 변경하려면 새 환경을 만들어야 합니다. 방법이 제공됩니다.
이 목적을 위해 기존 환경을 복사하는 경우). 다음과 같은 일부 내부 변수
`_IFLAGS'는 요청 시 생성되지만 일단 설정되면 수명 동안 고정된 상태로 유지됩니다.
환경을 제공합니다.

`CFLAGS', `LDFLAGS' 및 `ARFLAGS' 변수는 모두 옵션을 전달하기 위한 장소를 제공합니다.
각각 컴파일러, 로더, 아카이버입니다. 덜 명백하게, `INCDIRPREFIX'
변수는 각 포함의 시작 부분에 추가될 옵션 문자열을 지정합니다.
컴파일러가 찾을 위치를 알 수 있도록 디렉터리 .h 파일. 마찬가지로,
`LIBDIRPREFIX' 변수는 옵션 문자열의 시작 부분에 추가되도록 지정합니다.
링커가 라이브러리를 검색해야 하는 각 디렉터리입니다.

또 다른 변수 `ENV'는 실행 중 시스템 환경을 결정하는 데 사용됩니다.
외부 명령의. 기본적으로 설정되는 유일한 환경 변수는 'PATH'입니다.
이는 UNIX 명령의 실행 경로입니다. 최대한의 재현성을 위해서는 다음을 수행해야 합니다.
실제로 최상위 수준에서 자신만의 실행 경로를 설정하도록 준비합니다. 건설하다 파일 (또는
아마도 Perl `use' 명령을 사용하여 적절한 구성 패키지를 가져오는 것이 좋습니다.) 그만큼
기본 변수는 여러분을 시작하게 하기 위한 것입니다.

보간 구조 변수

생성 환경 변수는 소스 및 대상 파일 이름에 삽입될 수 있습니다.
구성 변수 이름 앞에 `%'를 붙여서.

$env = 새로운 단점(
DESTDIR => '프로그램',
SRCDIR => 'src',
);
프로그램 $env '%DESTDIR/hello', '%SRCDIR/hello.c';

구성 변수의 확장은 재귀적입니다. 즉, 파일 name(들)은 다시
더 이상 대체할 수 없을 때까지 확장됩니다. 구성 변수가 아닌 경우
환경에 정의된 경우 null 문자열이 대체됩니다.

태만 구조 방법

기본 구성 방법 목록에는 다음이 포함됩니다.

XNUMXD덴탈의 '새로운' 건설자

`new' 메소드는 Perl 객체 생성자입니다. 즉, 참조를 통해 호출되지 않습니다.
기존 건설 환경에 참고, 그러나 오히려 정적으로 이름을 사용하여
펄의 꾸러미 생성자가 정의된 곳입니다. 메소드는 다음과 같이 호출됩니다.

$env = 새로운 단점( );

당신이 돌려받은 환경은 'cons' 패키지에 축복을 받습니다.
아래에 설명된 기본 메서드와 연결되어 있습니다. 개별 공사
재정의 목록에 이름/값 쌍을 제공하여 변수를 재정의할 수 있습니다. 참고하세요
명령 환경 변수(예: `ENV' 아래의 모든 변수)를 무시하려면 다음을 수행해야 합니다.
그들 모두를 무시하십시오. 당신은 `복사' 방법을 사용함으로써 이 어려움을 해결할 수 있습니다.
기존 건설 환경.

XNUMXD덴탈의 '클론' 방법

'clone' 방법은 기존 구성 환경의 복제본을 생성하며 다음과 같은 작업을 수행할 수 있습니다.
다음 예제와 같이 호출됩니다.

$env2 = $env1->클론( );

일반적인 방식으로 재정의를 제공하여 기존 환경과 다른 환경을 만들 수 있습니다.
원래의. 동일한 환경에 대해 새 이름을 원하는 경우(다음 경우에 도움이 될 수 있음)
환경을 기존 구성 요소로 내보내는 경우) 간단한 할당을 사용하면 됩니다.

XNUMXD덴탈의 '복사' 방법

'복사' 방법은 외부에서 정의된 구성 변수를 추출합니다.
환경을 검색하고 이를 이름/값 쌍의 목록으로 반환합니다. 재정의도 가능합니다.
단, 이 경우 재정의된 값이 적절하게 반환됩니다. 그만큼
반환된 목록은 아래 프로토타입에 표시된 것처럼 해시에 할당될 수 있지만
다른 방법으로 조작될 수 있습니다:

%env = $env1->복사( );

그 자체가 해시인 `ENV'의 값도 새로운 해시에 복사되므로 이는 다음과 같을 수 있습니다.
원래 환경에 영향을 미칠 염려 없이 변경되었습니다. 예를 들어, 만약 당신이 정말로
기본 환경에서 `PATH' 변수만 재정의하려면 다음을 수행할 수 있습니다.
다음 :

%cons = 새로운 cons()->copy();
$cons{ENV}{PATH} = " ";
$cons = 새로운 단점(%cons);

이렇게 하면 기본 실행 환경에 있을 수 있는 다른 모든 항목이 남게 됩니다.
방해받지 않은.

XNUMXD덴탈의 `설치' 방법

`Install' 메소드는 지정된 파일이 지정된 위치에 설치되도록 준비합니다.
예배 규칙서. 설치가 최적화되었습니다. 파일이 링크될 수 있으면 복사되지 않습니다. 만약에
이는 원하는 동작이 아닙니다. 다른 방법을 사용하여 설치해야 합니다.
파일. 다음과 같이 호출됩니다.

$env 설치 , ;

설치할 파일의 이름은 임의로 지정할 수 있지만 마지막 파일만 이름을 지정할 수 있습니다.
각 이름의 구성 요소는 설치된 대상 이름에 사용됩니다. 예를 들어, 만약 당신이
설치를 준비하다 푸/바 in 바즈, 이렇게 하면 바 에 파일을 바즈 디렉토리(아님
푸/바).

XNUMXD덴탈의 '다른 이름으로 설치' 방법

`InstallAs' 메소드는 지정된 소스를 정렬합니다. 파일(s)는 다음과 같이 설치됩니다.
지정된 대상 파일(에스). 여러 파일을 파일 목록으로 지정해야 합니다. 그만큼
설치가 최적화되었습니다. 파일을 연결할 수 있으면 파일이 복사되지 않습니다. 이것이 아니라면
원하는 동작을 수행하려면 다른 방법을 사용하여 파일을 설치해야 합니다. 그것은
다음과 같이 호출됩니다:

`InstallAs'는 두 가지 방식으로 작동합니다:

단일 파일 설치:

InstallAs $env TgtFile, SrcFile;

다중 파일 설치:

InstallAs $env ['tgt1', 'tgt2'], ['src1', 'src2'];

또는 다음과 같이 해도 됩니다.

@srcs = qw(src1 src2 src3);
@tgts = qw(tgt1 tgt2 tgt3);
InstallAs $env [@tgts], [@srcs];

대상 목록과 소스 목록의 길이는 모두 동일해야 합니다.

XNUMXD덴탈의 '귀중하다' 방법

`Precious' 방법은 cons에게 지정된 파일이나 파일 목록을 삭제하기 전에 삭제하지 않도록 요청합니다.
다시 짓습니다. 다음과 같이 호출됩니다.

귀중한 ;

이는 라이브러리 또는 디버그에 대한 증분 업데이트를 허용하는 데 특히 유용합니다.
매번 새로 작성되지 않고 업데이트되는 정보 파일입니다. 단점은 여전히
`-r' 플래그가 지정되면 파일을 삭제하십시오.

XNUMXD덴탈의 '명령' 방법

'Command' 방법은 외부 명령을 처리하는 데 사용할 수 있는 포괄적인 방법입니다.
대상을 업데이트하기 위해 호출되는 명령입니다. 이 명령의 경우 대상 파일과 목록
입력이 제공됩니다. 추가로 구성 명령줄이 제공됩니다.
문자열(이 문자열에는 새 문자로 구분된 여러 명령이 포함될 수 있습니다.
윤곽). '명령'은 다음과 같이 호출됩니다.

$env 명령 , , ;

대상은 지정된 입력 파일 목록에 따라 달라지며 입력은 다음과 같아야 합니다.
성공적으로 빌드되지 않으면 Cons는 타겟 빌드를 시도하지 않습니다.

구성 명령 내에서 구성 환경의 모든 변수는 다음과 같습니다.
구성 변수의 이름 앞에 '%'를 붙여서 소개됩니다. 이는 재귀적입니다.
더 이상 대체할 수 없을 때까지 명령이 확장됩니다. 건축인 경우
변수가 환경에 정의되어 있지 않으면 null 문자열이 대체됩니다. ㅏ
두 배로 늘어난 `%%'는 구성 명령에서 단일 `%'로 대체됩니다.

확장될 여러 의사 변수도 있습니다:

%> 대상 파일 이름(다중 대상 명령에서는 항상 첫 번째 대상임)
말하는).

%0 `%>'와 같습니다.

%1, %2, ..., %9
이는 각각 첫 번째부터 아홉 번째 입력 파일을 참조합니다.

%< 전체 입력 세트입니다. 이들 중 하나가 다른 곳에서 사용된 경우
현재 명령줄(`%1', `%2' 등을 통해), 그러면 그것들은
목록은 `%<'에 의해 제공됩니다. 다음 명령을 고려해보세요. 징집 파일
FBI 증오 범죄 보고서 test 예배 규칙서:

명령 $env 'tgt', qw(foo bar baz), qq(
에코 %< -i %1 > %>
에코 %< -i %2 >> %>
에코 %< -i %3 >> %>
);

If tgt 업데이트해야 하는 경우 이로 인해 다음이 실행됩니다.
다음 명령에 대해 리매핑이 설정되지 않았다고 가정합니다. test
예배 규칙서:

에코 테스트/바 테스트/baz -i 테스트/foo > 테스트/tgt
에코 테스트/foo 테스트/baz -i 테스트/바 >> 테스트/tgt
에코 테스트/foo 테스트/bar -i 테스트/baz >> 테스트/tgt

위의 의사 변수 중 하나 바로 뒤에 다음 중 하나가 올 수 있습니다.
확장된 경로 이름의 일부를 선택하는 접미사:

:a 파일 이름의 절대 경로
:b 디렉토리와 접미사가 제거된 파일 이름
:d 디렉토리
:f 파일 이름
:s 파일 이름 접미사
:F 접미사가 제거된 파일 이름

위의 예를 계속하면 `%<:f'는 `foo bar baz'로 확장되고 `%':d>는
'테스트'로 확장하세요.

명령의 일부를 묶어서 프로그래밍 방식으로 명령의 일부를 다시 작성할 수 있습니다.
`%['와 `%]' 사이. 그러면 첫 번째 단어로 명명된 구성 변수가 호출됩니다.
Perl 코드 참조로 대괄호 안에 표시됩니다. 이 호출의 결과가 사용됩니다
명령줄에서 대괄호의 내용을 바꾸려면 예를 들어, 주어진
이름이 지정된 기존 입력 파일 tgt.in:

@keywords = qw(foo bar baz);
$env = new cons(X_COMMA => sub { Join(",", @_) });
명령 $env 'tgt', 'tgt.in', qq(
echo '# 키워드: %[X_COMMA @keywords %]' > %>
고양이 %< >> %>
);

다음이 실행됩니다.

echo '# 키워드: foo,bar,baz' > tgt
고양이 tgt.in >> tgt

대체가 발생한 후 공백 문자열은 단일 공백으로 변환됩니다.
선행 및 후행 공백이 제거됩니다. 그러므로 소개할 수 없다.
문자열의 가변 길이 공백은 일부에 의존하지 않고 명령에 전달됩니다.
일종의 쉘 인용.

여러 줄의 명령 문자열이 제공되면 명령이 순차적으로 실행됩니다. 만약에 어떠한
명령 중 하나가 실패하면 나머지 명령은 모두 실행되지 않으며 대상은 다음으로 표시되지 않습니다.
업데이트되었습니다. 즉, 대상에 대한 새 서명이 저장되지 않습니다.

일반적으로 모든 명령이 성공하면 XNUMX 상태(또는 어떤 플랫폼이든)를 반환합니다.
성공에 대한 구체적인 표시가 필요함) 그런 다음 새 서명이 저장됩니다.
표적. 명령이 실패 후에도 성공을 잘못 보고하는 경우 Cons는
해당 명령으로 생성된 대상 파일이 정확하고 최신이라고 가정합니다.

확장 후 각 명령 문자열의 첫 번째 단어는 실행 가능한 것으로 간주됩니다.
명령은 `PATH' 환경 변수를 찾았습니다.
`ENV' 구성 변수). 이 명령이 경로에서 발견되면 대상은
이에 의존합니다. 따라서 필요에 따라 명령이 자동으로 빌드됩니다. 그것은
세미콜론으로 구분하여 일부 쉘에 다중 부분 명령을 작성할 수 있습니다. 오직
그러나 첫 번째 명령 단어는 의존하므로 명령 문자열을 작성하면
이런 식으로, 당신은 명시적으로 종속성을 설정해야 합니다(`Depends' 메소드를 사용하여).
사용 중인 명령이 예상되는 시스템 명령인지 확인하십시오.
사용 가능. 사용할 수 없으면 당연히 오류가 발생합니다.

명령(여러 줄 명령 내의 명령이라도)이 '[perl]'로 시작하면 나머지는
해당 명령줄은
껍데기. Perl 구문 분석 중 오류가 발생하거나 Perl 표현식이 0을 반환하거나
undef를 사용하면 명령이 실패한 것으로 간주됩니다. 예를 들어, 다음은 간단한 예입니다.
Perl에서 직접 `foo' 파일을 생성하는 명령:

$env = 새로운 단점();
$env 'foo' 명령,
qq([perl] open(FOO,'>foo');print FOO "hi\\n"; close(FOO); 1);

명령이 실행될 때와 동일한 패키지에 있다는 점에 유의하십시오. 건설하다
or 징집 파일을 읽었으므로 동일한 파일에서 정의한 Perl 함수를 호출할 수 있습니다.
건설하다 or 징집 'Command'가 나타나는 파일:

$env = 새로운 단점();
하위 create_file {
내 $file = 교대;
open(FILE, ">$file");
FILE "hi\n" 인쇄;
닫기(파일);
1가 돌아;
}
명령 $env 'foo', "[perl] &create_file('%>')";

Perl 문자열은 파생된 파일에 대한 서명을 생성하는 데 사용됩니다.
문자열을 변경하면 파일이 다시 작성됩니다. 호출하는 서브루틴의 내용,
그러나 서명의 일부가 아니므로 다음과 같이 호출된 서브루틴을 수정하는 경우
위의 `create_file'을 사용하면 대상이 지원 재건축되다. 주의사항 사용자입니다.

Cons는 일반적으로 명령을 실행하기 전에 명령을 인쇄합니다. 이 동작은 다음과 같은 경우 억제됩니다.
명령의 첫 번째 문자는 '@'입니다. `@'를 분리해야 할 수도 있습니다.
Perl 인용문에 따르면 `@cmd'가 배열처럼 보이지 않도록 명령 이름을 삭제하거나 이스케이프 처리하세요.
보간을 수행하는 연산자:

# 첫 번째 명령줄이 올바르지 않습니다.
# "@cp"가 배열처럼 보이기 때문입니다.
# Perl qq// 함수에.
# 대신 두 번째 형식을 사용하세요.
명령 $env 'foo', 'foo.in', qq(
@cp %< 임시 파일
@cp 임시파일 %>
);

`<'와 같은 확장된 명령줄의 어느 곳에나 쉘 메타 문자가 있는 경우,
`>', 따옴표 또는 세미콜론을 사용하면 명령이 실제로 호출되어 실행됩니다.
껍데기. 이는 다음과 같은 명령을 의미합니다.

시디 푸

경로에 `cd' 명령이 없기 때문에 단독으로는 일반적으로 실패합니다. 그러나 명령은
끈:

CD $<:d; 타르 참조 $>:f $<:f

확장되면 여전히 쉘 메타 문자 세미콜론이 포함되며 쉘은
명령을 해석하기 위해 호출됩니다. `cd'는 이 하위 쉘에 의해 해석되므로, 명령은
예상대로 실행됩니다.

여러 대상이 있는 명령을 지정하려면 다음 목록에 대한 참조를 지정할 수 있습니다.
목표. Perl에서는 목록을 대괄호로 묶어 목록 참조를 만들 수 있습니다.
따라서 다음 명령은 다음과 같습니다.

명령 $env ['foo.h', 'foo.c'], 'foo.template', q(
세대% 1
);

`gen' 명령이 두 개의 파일을 생성하는 경우에 사용될 수 있습니다. 푸.h 과 foo.c.

XNUMXD덴탈의 '객체' 방법

`Objects' 메소드는 지정된 파일에 해당하는 객체 파일을 생성하도록 정렬합니다.
소스 파일. 아래와 같이 호출됩니다.

@files = 객체 $env ;

Unix에서는 다음으로 끝나는 소스 파일 .s 과 .c 현재 지원되며 컴파일될 예정입니다.
다음으로 끝나는 동일한 파일의 이름으로 .o. 기본적으로 모든 파일은 다음을 호출하여 생성됩니다.
'CCCOM' 구성 변수를 확장한 결과로 생성된 외부 명령은 다음과 같습니다.
`%<' 및 `%>'는 각각 소스 파일과 객체 파일로 설정됩니다(`Command' 메소드 참조).
확장 세부사항은 참조). 'CPPPATH' 변수는 소스 파일을 스캔할 때도 사용됩니다.
종속성을 위해. 이는 콜론으로 구분된 경로 이름 목록이며, 생성하는 데에도 사용됩니다.
-`I'의 적절한 목록을 포함하는 구성 변수 `_IFLAGS'
편집 옵션. `CPPPATH'의 모든 상대 경로 이름은 상대 경로로 해석됩니다.
관련 구성 환경이 생성된 디렉터리(절대
최상위 상대 이름도 사용될 수 있습니다). 이 변수는 `CCCOM'에 의해 사용됩니다. 그 행동
이 명령은 보간된 변수를 변경하여 수정할 수 있습니다.
`CC', `CFLAGS', 그리고 간접적으로는 `CPPPATH'와 같은 `CCCOM'으로 변환됩니다. 또한 가능합니다
`CCCOM' 자체의 값을 대체합니다. 편의상 이 파일은 다음 목록을 반환합니다.
개체 파일 이름.

XNUMXD덴탈의 '프로그램' 방법

'Program' 메소드는 지정된 프로그램을 지정된 개체와 연결하도록 배열합니다.
파일. 다음과 같은 방식으로 호출됩니다.

프로그램 $env , ;

프로그램 이름에는 `SUFEXE' 구성 변수의 값이 추가됩니다(
기본값, Win32 시스템에서는 `.exe', Unix 시스템에서는 아무것도 없음) 접미사가 아직 지정되지 않은 경우
선물.

객체 파일 대신 소스 파일을 지정할 수 있습니다. `Objects' 메소드는 다음과 같습니다.
모든 파일을 객체 파일로 변환하기 위해 호출됩니다.
위의 `Objects' 메소드에 대한 관찰은 이 메소드에도 적용됩니다.

프로그램의 실제 연결은 결과적으로 외부 명령에 의해 처리됩니다.
객체 파일에 설정된 `%<'를 사용하여 `LINKCOM' 구성 변수를 확장하는 것부터
(표시된 순서대로) 연결되고 `%>'가 대상으로 설정됩니다(`Command' 메소드 참조).
확장 세부사항은 참조). 사용자는 구성 시 추가 변수를 설정할 수 있습니다.
연결에 사용할 프로그램을 정의하기 위한 `LINK'를 포함한 환경, `LIBPATH'
라이브러리 사양과 함께 사용하기 위한 콜론으로 구분된 라이브러리 검색 경로 목록
형태 -llib, 그리고 `LIBS', 링크할 라이브러리 목록 지정(둘 중 하나) -llib
형식 또는 경로 이름으로 사용됩니다. `LIBPATH' 및 `LIBS' 모두의 상대 경로 이름이 해석됩니다.
연관된 구성 환경이 생성되는 디렉토리를 기준으로 합니다.
(절대 및 최상위 상대 이름도 사용할 수 있습니다). 단점은 자동으로 설정됩니다.
`LIBS'에 언급된 라이브러리에 대한 종속성: 해당 라이브러리는 이전에 빌드됩니다.
명령이 연결되었습니다.

XNUMXD덴탈의 '도서관' 방법

`Library' 메소드는 지정된 객체로부터 지정된 라이브러리를 생성하도록 배열합니다.
파일. 다음과 같이 호출됩니다.

라이브러리 $env , ;

라이브러리 이름에는 'SUFLIB' 구성 변수 값이 추가됩니다(
기본값, Win32 시스템에서는 `.lib', Unix 시스템에서는 `.a') 접미사가 아직 지정되지 않은 경우
선물.

객체 파일 대신 소스 파일을 지정할 수 있습니다. `Objects' 메소드는 다음과 같습니다.
모든 파일을 객체 파일로 변환하기 위해 호출됩니다.
위의 `Objects' 메소드에 대한 관찰은 이 메소드에도 적용됩니다.

라이브러리의 실제 생성은 외부 명령에 의해 처리되며 그 결과는 다음과 같습니다.
`%<'를 라이브러리 멤버로 설정하여 `ARCOM' 구성 변수를 확장하는 것(
제시된 순서) 및 `%>'를 생성될 라이브러리에 추가합니다('Command' 메소드 참조).
확장 세부정보). 사용자는 구성 환경에서 변수를 설정할 수 있습니다.
명령 작동에 영향을 미칩니다. 여기에는 사용할 아카이브 프로그램인 'AR'이 포함됩니다.
`AR'에 의해 지정된 프로그램에 주어진 플래그를 수정하는데 사용될 수 있는 `ARFLAGS',
그리고 필요한 경우 아카이브 인덱스 생성 프로그램의 이름인 'RANLIB'(특정한 경우)
필요에 따라 후자의 기능이 필요하지 않으면 'ARCOM'을 재정의해야 합니다.
참조 `RANLIB').

`라이브러리' 메소드를 사용하면 동일한 라이브러리를 여러 메소드로 지정할 수 있습니다.
호출. 모든 호출에서 기여하는 모든 개체(
다른 디렉터리)은 단일 아카이브 명령으로 결합되고 생성됩니다. 메모,
그러나 라이브러리의 일부만 지정되도록 빌드를 정리하면
라이브러리의 해당 부분이 생성됩니다(나머지는 사라집니다!).

XNUMXD덴탈의 '모듈' 방법

'모듈' 방식은 '프로그램' 방식과 '명령' 방식을 조합한 것입니다. 보다는
실행 가능한 프로그램을 직접 생성하는 경우 이 명령을 사용하면 자신만의 프로그램을 지정할 수 있습니다.
실제로 모듈을 생성하는 명령입니다. 메소드는 다음과 같이 호출됩니다.

모듈 $env , , ;

이 명령은 예를 들어 동적으로 생성하려는 경우에 유용합니다.
로드된 모듈 또는 정적으로 링크된 코드 ​​라이브러리.

XNUMXD덴탈의 '의존한다' 방법

`Depends' 메소드를 사용하면 대상에 대한 추가 종속성을 지정할 수 있습니다. 그것은
다음과 같이 호출됩니다.

$env에 따라 다름 , ;

이는 특히 스캐너가 없는 경우(또는 스캐너가 없는 경우) 유용할 수 있습니다.
쓰기 가능) 특정 유형의 파일에 대해. 일반적으로 종속성은 계산됩니다.
메소드에 의해 설정된 명시적 종속성의 조합에서 자동으로
호출 또는 소스 파일 스캔을 통해.

여러 대상에 대한 동일한 종속성 세트는 다음 참조를 사용하여 지정할 수 있습니다.
대상 목록. Perl에서는 목록을 사각형으로 묶어 목록 참조를 만들 수 있습니다.
괄호. 따라서 다음 명령은 다음과 같습니다.

$env ['foo', 'bar'], 'input_file_1', 'input_file_2'에 따라 다릅니다.

두 가지 모두를 지정합니다. 푸 과 바 파일은 나열된 입력 파일에 따라 달라집니다.

XNUMXD덴탈의 '무시' 방법

`Ignore' 메소드를 사용하면 Cons가 추론하는 종속성을 명시적으로 무시할 수 있습니다.
소유하다. 다음과 같이 호출됩니다.

무시하다 ;

이는 시스템 헤더 파일의 변경으로 인한 재컴파일을 방지하는 데 사용할 수 있습니다.
생성된 대상에 영향을 주지 않는 것으로 알려진 유틸리티입니다.

예를 들어, 프로그램이 여러 시스템의 NFS 마운트 디렉토리에 구축된 경우
서로 다른 사본을 갖고 있다 stdio.h, 차이점은 모든 서명에 영향을 미칩니다
`#include 소스 파일에서 빌드된 파생 타겟 '. 이로 인해 모든
시스템을 변경할 때 재구축할 대상입니다. 이것이 바람직하지 않은 행동이라면,
다음 줄은 stdio.h 파일 :

'^/usr/include/stdio\.h$' 무시;

`Ignore' 메소드에 대한 인수는 정규 표현식이므로 특별합니다.
문자는 이스케이프되어야 하며 문자의 시작이나 끝을 고정할 수 있습니다.
`^' 또는 `$' 문자를 사용한 표현식입니다.

XNUMXD덴탈의 '소금' 방법

'Salt' 방법은 파생된 모든 서명 계산에 상수 값을 추가합니다.
파일. 다음과 같이 호출됩니다.

솔트 $string;

Salt 값을 변경하면 파생된 모든 파일이 완전히 다시 빌드됩니다. 이것은 될 수있다
원하는 특정 상황에서 강제로 재구축하는 데 사용됩니다. 예를 들어,

솔트`uname -s`;

운영 체제가 켜질 때마다 모든 파생 파일을 강제로 완전히 다시 빌드합니다.
빌드가 수행되는 것(`uname -s'에 의해 보고된 대로)이 변경됩니다.

XNUMXD덴탈의 '캐시 사용' 방법

`UseCache' 메소드는 공유될 파생 파일의 캐시를 유지하도록 Cons에 지시합니다.
동일한 프로젝트의 별도 빌드 트리 사이에서.

UseCache("캐시/ ") ⎪⎪ warning("캐시 디렉터리를 찾을 수 없습니다.");

XNUMXD덴탈의 `소스 경로' 방법

`SourcePath' 수학은 파일의 실제 소스 경로 이름을 반환합니다.
빌드 디렉터리 내의 경로 이름입니다. 다음과 같이 호출됩니다.

$path = 소스패스 ;

XNUMXD덴탈의 `단점 경로' 방법

'ConsPath' 메소드는 제공된 경로가 파생 가능한 파일인 경우 true를 반환하고 다음을 반환합니다.
그렇지 않으면 undef (false)입니다. 다음과 같이 호출됩니다.

$result = ConsPath ;

XNUMXD덴탈의 '분할경로' 방법

`SplitPath' 메소드는 기본값으로 구분된 문자열에서 여러 경로 이름을 찾습니다.
운영 체제의 경로 구분 기호(UNIX 시스템에서는 ':', Windows NT에서는 ';')
완전한 이름을 반환합니다. 다음과 같이 호출됩니다.

@paths = 분할경로 ;

`SplitPath' 메소드는 '#' 접두사가 붙은 이름을 적절한 최상위 빌드로 변환합니다.
이름('#' 제외)을 사용하고 상대 이름을 최상위 이름으로 변환합니다.

XNUMXD덴탈의 `DirPath' 방법

`DirPath' 메소드는 빌드 경로를 반환합니다. name(들) 디렉토리 또는 디렉토리 목록.
다음과 같이 호출됩니다.

$cwd = DirPath ;

`DirPath' 메소드의 가장 일반적인 용도는 다음과 같습니다:

$cwd = DirPath '.';

자회사의 현재 디렉터리에 대한 경로를 가져오려면 징집 파일.

XNUMXD덴탈의 `파일 경로' 방법

`FilePath' 메소드는 빌드 경로를 반환합니다. name(들) 파일 또는 파일 목록. 그것은
다음과 같이 호출됩니다.

$file = 파일 경로 ;

XNUMXD덴탈의 '도움말' 방법

`Help' 메소드는 사용자가 `cons'를 호출할 때 표시될 도움말 텍스트를 지정합니다.
-시간'. 이는 특정 대상, 값, 빌드에 대한 문서를 제공하는 데 사용될 수 있습니다.
빌드 트리에 대한 옵션 등. 다음과 같이 호출됩니다.

돕다 ;

'Help' 메소드는 한 번만 호출할 수 있으며 일반적으로 상단에 지정해야 합니다.
수평 건설하다 파일.

확장 단점

재정의 구조 변수

난이도에 따라 Cons를 확장하는 방법에는 여러 가지가 있습니다. 가장 간단한
방법은 기본 환경을 기반으로 자신만의 구축 환경을 정의하는 것입니다.
그러나 귀하의 특정 요구 사항을 반영하도록 수정되었습니다. 이것은 종종 C 기반의 경우 충분합니다.
응용 프로그램. `new' 생성자와 `clone' 및 `copy' 메소드를 사용하여 다음을 수행할 수 있습니다.
하이브리드 환경을 만듭니다. 이러한 변경 사항은 기본 프로세스에 완전히 투명할 수 있습니다.
징집 파일.

첨가 방법

약간 더 까다로운 변경을 위해서는 `cons'에 새로운 메소드를 추가하는 것이 좋습니다.
패키지. 다음은 매우 간단한 확장 'InstallScript'의 예입니다.
tcl 스크립트를 요청한 위치에 배치하지만 플랫폼을 반영하기 위해 먼저 스크립트를 편집합니다.
스크립트에 설치해야 하는 종속 경로:

# 단점::InstallScript - 플랫폼에 따른 쉘 버전 생성
# 문자열 ``#!your-path-here''를 플랫폼별 문자열로 대체하여 스크립트
# 경로 $BIN_DIR.

하위 단점::InstallScript {
내 ($env, $dst, $src) = @_;
명령 $env $dst, $src, qq(
sed s+your-path-here+$BIN_DIR+ %< > %>
chmod oug+x %>
);
}

이 메소드는 `cons' 패키지에 직접 정의되어 있습니다(이름 앞에 이름을 붙여서).
`단점::'). 이러한 방식으로 변경된 내용은 모든 환경에 전역적으로 표시됩니다.
다음 예제와 같이 호출될 수 있습니다.

InstallScript $env "$BIN/foo", "foo.tcl";

일반성을 약간 개선하기 위해 'BINDIR' 변수를 다음과 같이 전달할 수 있습니다.
인수 또는 구성 환경에서 가져옵니다--`%BINDIR'.

재정의 방법

'cons' 네임스페이스에 메소드를 추가하는 대신 새 패키지를 정의할 수 있습니다.
이는 `cons' 패키지의 기존 메소드를 상속하고 다른 메소드를 대체하거나 추가합니다. 이것
Perl의 상속 메커니즘을 사용하여 수행할 수 있습니다.

다음 예는 표준을 재정의하는 새로운 패키지 `cons::switch'를 정의합니다.
'라이브러리' 방법. 재정의된 메서드는 라이브러리가 아닌 연결된 라이브러리 모듈을 빌드합니다.
아카이브. 새로운 생성자가 제공됩니다. 이 생성자로 생성된 환경은
새로운 라이브러리 방식을 사용하세요. 다른 사람들은 그렇지 않을 것입니다.

패키지 단점::스위치;
시작 {@ISA = '단점'}

하위 새 {
옮기다;
새로운 단점을 축복해주세요(@_);
}

하위 라이브러리 {
my($env) = 시프트;
my($lib) = 시프트;
my(@objs) = 개체 $env @_;
명령 $env $lib, @objs, q(
%LD -r %LDFLAGS %< -o %>
);
}

이 기능은 다음 예와 같이 호출될 수 있습니다.

$env = 새로운 단점::switch(@overrides);
...
라이브러리 $env 'lib.o', 'foo.c', 'bar.c';

호출 단점

`cons' 명령은 일반적으로 빌드 트리의 루트에서 호출됩니다. ㅏ 건설하다 파일
해당 디렉터리에 있어야 합니다. `-f' 인수가 사용되면 대체 건설하다
파일을 사용할 수 있습니다(그리고 대체 루트도 가능합니다. 'cons'가 다음으로 CD를 실행하기 때문입니다) 건설하다
파일이 포함된 디렉터리).

`cons'가 `-t' 인수를 사용하여 빌드 트리 루트의 하위에서 호출되면,
디렉토리 계층 구조를 탐색하여 건설하다 파일. (대체 이름은
여전히 `-f'로 지정됩니다.) 명령줄에 제공된 대상은 수정됩니다.
발견된 것과 관련이 있다 건설하다 파일. 예를 들어 다음을 포함하는 디렉토리에서
최상위 건설하다 파일에서 다음 호출:

% CD libfoo/하위 디렉터리
% 단점 -t 대상

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

% 단점 libfoo/하위 디렉터리/대상

디렉터리 계층 구조에 '기본' 대상이 지정된 경우 건설하다 or
징집 파일, `cons -t'가 있는 디렉토리나 그 아래의 기본 대상만
호출되면 빌드됩니다.

명령은 다음과 같이 호출됩니다.

단점 --

어디에 인수 순서에 관계없이 다음 중 하나일 수 있습니다.

목표 지정된 대상을 빌드합니다. 만약에 목표 디렉터리이고 재귀적으로 빌드됩니다.
해당 디렉토리 내의 모든 것.

+패턴 한계 징집 일치하는 파일로만 간주되는 파일 무늬어느입니다
Perl 정규식. 여러 개의 '+' 인수가 허용됩니다.

name=
설정 name 가치에 파 최상위 레벨로 전달된 'ARG' 해시에서 건설하다 파일.

`-cc' 캐시에서 검색할 때 실행되었을 명령을 표시합니다. 아니요
파일이 검색되었다는 표시가 제공됩니다. 이것은 유용합니다
실제 빌드 로그와 비교할 수 있는 빌드 로그를 생성합니다.

`-cd' 모든 캐싱을 비활성화합니다. 캐시에서 검색하거나 캐시로 플러시하지 마세요.

`-cr' 무작위 순서로 종속성을 빌드합니다. 여러 개를 만들 때 유용합니다.
캐싱이 활성화된 유사한 트리.

`-cs' 최신인 것으로 확인된 기존 빌드 대상을 캐시와 동기화합니다.
-cc로 캐싱을 비활성화했거나 최근에 활성화한 경우에 유용합니다.
UseCache와 함께.

`-d' 종속성 디버깅을 활성화합니다.

`-f'
대신 지정된 파일을 사용하십시오. 건설하다 (그러나 먼저 포함으로 변경
디렉토리 파일).

`-h' 정의된 경우 현재 빌드에 대한 도움말 메시지를 표시하고 종료합니다.

`-k' 오류 후에도 가능한 한 계속 진행합니다.

`-오'
재정의 파일 읽기 파일.

`-p' 지정된 트리의 건설 제품을 표시합니다. 빌드가 시도되지 않습니다.

`-pa' 건설 제품 및 관련 작업을 표시합니다. 빌드가 시도되지 않습니다.

`-pw' 제품과 정의된 위치를 표시합니다. 빌드가 시도되지 않습니다.

`-q' 대상 설치 및 제거에 대해 장황하게 설명하지 마십시오.

`-r' 다음과 관련된 건축 제품을 제거합니다. . 빌드가 시도되지 않습니다.

`-R'
다음에서 파일 검색 repos. 배수 -R repos 디렉토리는 다음에서 검색됩니다.
주문 지정.

`-t' 디렉토리 계층 구조를 탐색하여 다음을 찾습니다. 건설하다 파일(존재하지 않는 경우)
현재 디렉토리에 있습니다. 대상은 다음을 기준으로 수정됩니다.
건설하다 파일.

`-v' `cons' 버전을 표시하고 계속 처리합니다.

`-V' `cons' 버전을 표시하고 종료합니다.

`-wf'
고려되는 모든 파일 이름을 작성하십시오. 파일.

`-x' 이와 유사한 도움말 메시지를 표시하고 종료합니다.

Audiencegain과 구성 인수 처리하려는 모든 인수가 될 수 있습니다. 건설하다 파일.
다음이 있어야 합니다. -- 반대 주장과 당신이 주장하는 주장을 분리하십시오.
에서 처리하고 싶습니다. 건설하다 파일.

가공 구성 인수 다음과 같은 표준 패키지로 수행할 수 있습니다. Getopt 또는
변형 또는 사용자 정의 패키지. 죄수 통과할 것이다 구성 인수 as @ARGV 과
이후에는 어떤 것도 해석하려고 시도하지 않습니다. --.

% 단점 -R /usr/local/repository -d os=solaris +driver -- -c 테스트 -f DEBUG

단점에 다음을 전달합니다

-R /usr/local/repository -d os=solaris +드라이버

다음은 최상위 수준 건설하다 파일로 @ARGV

-c 테스트 -f 디버그

'cons -r'에 주의하세요. 완전 재귀적인 'make clean'과 동일하지만
지원 건설하다 파일 또는 무엇이든 징집 파일. 다음과 같은 경우에 가장 유용합니다.
파일을 소스 디렉터리로 컴파일( 빌드 과 수출 디렉토리,
그런 다음 디렉터리를 제거하면 됩니다.)

`-p', `-pa', `-pw' 옵션은 읽기 보조 수단으로 사용하는 데 매우 유용합니다.
스크립트를 작성하거나 디버깅합니다. 어떤 스크립트가 설치되는지 알고 싶다면 내보내기/포함/foo.h,
예를 들어 다음과 같이 입력하면 됩니다.

% 단점 -pw 내보내기/포함/foo.h

사용 과 쓰기 의존 스캐너

QuickScan을 사용하면 소스 파일에 대해 간단한 대상 독립적 스캐너를 설정할 수 있습니다. 오직
하나의 QuickScan 스캐너는 특정 소스 파일 및 환경과 연결될 수 있습니다.

QuickScan은 다음과 같이 호출됩니다.

QuickScan CONSENV CODEREF, 파일 이름 [, PATH]

CODEREF에서 참조하는 서브루틴은 포함된 파일 이름 목록을 반환할 것으로 예상됩니다.
FILE로 직접. 그러면 이러한 파일 이름이 검사됩니다. 선택적 PATH 인수
FILENAME 및/또는 사용자 제공에서 반환된 파일을 찾기 위한 조회 경로를 제공합니다.
서브루틴. PATH는 조회 디렉터리 이름 배열에 대한 참조이거나
시스템의 구분 문자(UNIX 시스템에서는 ':', UNIX 시스템에서는 ';')로 구분된 이름 문자열
윈도우 NT).

서브루틴은 파일의 각 줄에 대해 한 번씩 호출되며 $_는 현재 줄로 설정됩니다.
서브루틴이 추가 행을 조사해야 하거나, 전체 파일을 조사해야 하는 경우,
그런 다음 파일 핸들 SCAN에서 자체적으로 읽을 수 있습니다. 다음과 같은 경우 루프가 종료될 수도 있습니다.
파일 핸들을 닫으면 더 이상 포함 정보를 사용할 수 없다는 것을 알 수 있습니다.

조회 경로 제공 여부에 관계없이 QuickScan은 먼저 파일 조회를 시도합니다.
현재 디렉토리를 기준으로 합니다(QuickScan에 직접 제공되는 최상위 파일의 경우).
또는 파일을 참조한 파일이 포함된 디렉터리에서. 이건 별로
일반적이지만 충분해 보입니다. 특히 직접 작성할 수 있는 여유가 있는 경우에는 더욱 그렇습니다.
유틸리티이며 표준 방식으로 검색 경로의 사용을 제어할 수 있습니다. 마지막으로,
검색 경로는 현재 콜론으로 구분되어 있습니다. 이것은 NT 캠프를 행복하게 만들지 못할 수도 있습니다.

다음은 실제 예입니다. 건설하다 여기에 파일:

하위 단점::SMFgen {
my($env, @tables) = @_;
foreach $t (@tables) {
$env->QuickScan(하위 { /\b\S*?\.smf\b/g }, "$t.smf",
$env->{SMF_INCLUDE_PATH});
$env->명령(
["$t.smdb.cc","$t.smdb.h","$t.snmp.cc","$t.ami.cc", "$t.http.cc"],
"$t.smf",
q(
smfgen %( %SMF_INCLUDE_OPT %) %
)
);
}
}

[`$env->QuickScan ...' 및 `$env->Command ...' 형식은 다음과 같지 않아야 함을 참고하세요.
필요하지만 어떤 이유로 이 특정 호출에는 필요합니다. 이 나타납니다
Perl의 버그이거나 내 부분의 오해입니다. 이 호출 스타일은 그렇지 않습니다
항상 필요한 것 같습니다.]

이것은 양식의 모든 이름을 찾습니다. .smf 파일입니다. 다음과 같은 경우에도 이름을 반환합니다.
주석 안에 있지만 괜찮습니다. 메커니즘은 추가 파일을 허용합니다.
누락된 파일이 발견될 것이라는 가정 하에 그들은 단지 무시됩니다.
프로그램(이 예에서는 smfgen이 실제로 호출됩니다).

스캐너는 특정 대상에서 필요한 경우에만 지정된 소스 파일에 대해 호출됩니다.
나무. 주어진 소스 파일에 대해 한 번만 호출됩니다.

동일한 스캐너를 만드는 또 다른 방법이 있습니다. 이것은 명시적인 코드 참조를 사용합니다.
또한 (이 경우 불필요하게) 전체 파일 자체를 읽습니다.

하위 myscan {
내(@includes);
하다 {
푸시(@includes, /\b\S*?\.smf\b/g);
} 하는 동안 ;
@포함
}

루프 테스트가 마지막에 있으므로 루프의 순서가 반대입니다. 이것은
첫 번째 줄은 이미 읽어졌기 때문입니다. 이 스캐너는 소스에 연결할 수 있습니다
파일 보관 방법:

QuickScan $env \myscan, "$_.smf";

고객지원 및 제안

단점은 사용자 커뮤니티에 의해 유지됩니다. 구독하려면 다음 주소로 메일을 보내세요. 반대-토론-
[이메일 보호] 몸으로 가입.

제안 사항이 있으면 신고해 주세요. [이메일 보호] 메일 링리스트.

onworks.net 서비스를 사용하여 온라인으로 단점을 사용하십시오.