critcl - 클라우드 온라인

프로그램:

이름

critcl-CriTcl 응용 프로그램

개요

크리티컬 ?선택권...? ?파일...?

_________________________________________________________________

기술

환영합니다 C 런타임 In Tcl, 크리티클 간단히 말해서 C 확장 패키지를 빌드하는 시스템입니다.
Tcl 스크립트에 포함된 C 코드에서 즉석에서 Tcl을 만들려는 모든 사람을 위해
코드가 더 빨라집니다.

이 문서는 다음에 대한 참조 맨페이지입니다. 크리티컬 명령. 대상 청중은 다음과 같습니다.
다음을 사용하여 패키지를 빌드해야 하는 사람들 크리티컬 배치를 위해. 패키지 작성자
포함된 C 코드는 이 문서를 무시할 수 있습니다. 전체 개요가 필요한 경우
대신 시스템으로 이동하여 개요 에 크리티클.

이 응용 프로그램은 CriTcl의 응용 프로그램 계층에 있습니다.

*==================*
|응용 프로그램 |
| 크리티컬 |
| 크리티컬::앱 |
*==================*

+----------------+
|핵심 패키지 |
| 크리티컬 |
| 크리티컬::유틸 |
+----------------+

+----------------+
|지원 패키지|
| 스텁::* |
| md5, 플랫폼 |
| ... |
+----------------+

애플리케이션은 다음 일반 명령줄을 지원합니다.

크리티컬 ?선택권...? ?파일...?
지원되는 정확한 옵션 세트, 해당 의미 및 상호 작용은 에 자세히 설명되어 있습니다.
섹션에 있어야 합니다. 어플리케이션 옵션 아래에. 더 큰 예제 세트는 섹션을 참조하십시오.
관련 문서의 "Building Critcl Packages" 사용 크리티클.

신청 옵션

다음 옵션이 이해됩니다.

-v

--번역
이러한 옵션을 사용하면 critcl이 해당 버전을 다음으로 인쇄합니다. 표준 출력 그런 다음 종료합니다.

-I 통로
이 옵션은 컴파일 중에 사용할 추가 전역 포함 경로를 지정합니다.
의 ".critcl" 파일. 이 값을 여러 번 지정하면 모든 값이 사용됩니다.

이 옵션은 TEA 패키지를 생성할 때 관련이 없습니다(옵션 참조). -차 아래).

-L 통로
이 옵션은 연결 중에 사용할 추가 전역 라이브러리 검색 경로를 지정합니다.
의 ".critcl" 파일. 이 값을 여러 번 지정하면 모든 값이 사용됩니다.

이 옵션은 TEA 패키지를 생성할 때 관련이 없습니다(옵션 참조). -차 아래).

-은닉처 통로
이 옵션은 결과 캐시로 사용할 디렉터리 경로를 지정합니다. 그렇지 않다면
기본값은 "~/.critcl/" 또는 패키지를 생성할 때(참조
선택권 -패키지 이하), "~/.critcl/.", 여러 번 지정하면
마지막 값이 사용됩니다.

이 옵션은 TEA 패키지를 생성할 때 관련이 없습니다(옵션 참조). -차 아래).

-깨끗한 지정된 경우 결과 캐시가 비워집니다. 즉, 발견된 모든 파일 및 디렉토리
내부는 삭제됨) 컴파일이 시작되기 전에.

이 옵션은 패키지를 생성할 때 관련이 없습니다(옵션 참조). -패키지 이하) 때문에
이 모드는 고유하고 비어 있는 결과 캐시로 시작합니다.

이 옵션은 TEA 패키지를 생성할 때 관련이 없습니다(옵션 참조). -차 아래).

-구성 통로
이 옵션은 사용자 지정 구성 파일의 경로를 지정하여 사용자가 다음을 수행할 수 있도록 합니다.
자체 대상 사양을 사용합니다. 지정되지 않은 경우 유선 기본값
시스템 코어에 내장된 구성이 대신 사용됩니다. 여러 개를 지정한 경우
마지막 값이 사용된 횟수입니다.

이 옵션은 TEA 패키지를 생성할 때 관련이 없습니다(옵션 참조). -차 아래).

-디버그 모드
이 옵션은 디버깅과 함께 컴파일을 활성화합니다. 아래의 모드를 허용합니다. 언제
여러 번 지정된 모든 모드의 조합이 사용됩니다.

이 옵션은 TEA 패키지를 생성할 때 관련이 없습니다(옵션 참조). -차 아래).

기억 이 모드는 Tcl을 통해 할당된 메모리 디버깅을 활성화합니다.
핵심.

기호
이 모드는 모든 ".c" 디버깅 기호가 있는 파일.

모든 이 모드는 둘 다 활성화합니다. 기억 과 기호.

-장애를 입히다 name
이 옵션은 사용자 지정 빌드 구성 옵션의 값을 설정합니다. name 에 그릇된.
"-with-"와 동일합니다.name 0 "

정보는 ".critcl" 실제 입력 파일
사용자 지정 빌드 구성 옵션을 정의하고 사용합니다. name.

이 옵션은 TEA 패키지를 생성할 때 관련이 없습니다(옵션 참조). -차 아래).

-할 수있게하다 name
이 옵션은 사용자 지정 빌드 구성 옵션의 값을 설정합니다. name 에 참된.
"-with-"와 동일합니다.name 1 "

정보는 ".critcl" 실제 입력 파일
사용자 지정 빌드 구성 옵션을 정의하고 사용합니다. name.

이 옵션은 TEA 패키지를 생성할 때 관련이 없습니다(옵션 참조). -차 아래).

-힘 지정된 컴파일이 항상 수행되면 파일에 대한 공유 라이브러리가 있더라도
이미 존재합니다. 이 효과는 다음과 같이 캐시 정리(위 참조)를 통해 얻을 수 있습니다.
글쎄, 파일 파괴에 게으르고 파일을 파괴하지 않는다는 점을 제외하면
우리가 만들고 있는 것과는 관련이 없습니다.

이 옵션은 패키지를 생성할 때 관련이 없습니다(옵션 참조). -패키지 이하) 때문에
이 모드는 고유하고 비어 있는 결과 캐시로 시작합니다.

이 옵션은 TEA 패키지를 생성할 때 관련이 없습니다(옵션 참조). -차 아래).

-도움 이 옵션을 사용하면 시스템이 명령줄 구문에 대한 간단한 도움말을 인쇄합니다.
및 옵션을 선택한 다음 응용 프로그램을 종료합니다.

-유지하다 이 옵션을 사용하면 시스템이 ".c" 실행에 의해 생성된 파일은
결과 캐시. 패키지를 생성할 때(옵션 참조 -패키지 아래) 이것은 또한 방지
실행에 사용된 고유한 결과 캐시 삭제. 이 옵션은
디버깅을 위해 크리티컬 자체 검사가 필요할 수 있습니다.
생성된 C 코드.

이 옵션은 TEA 패키지를 생성할 때 관련이 없습니다(옵션 참조). -차 아래).

-libdir 통로
이 옵션은 옵션을 통해 생성된 패키지의 경로를 지정합니다. -패키지
저장됩니다. 또한 다음과 같이 라이브러리를 검색할 경로를 지정합니다. -L. 언제
여러 번 지정하면 마지막 값이 사용됩니다. 전혀 지정되지 않은 경우
기본, "lib"가 사용됩니다. 이것이 어떻게 상대 경로인지 확인하고 결과를 다음 위치에 배치합니다.
현재 작업 디렉토리.

-포함디렉터리 통로
이 옵션은 생성된 패키지 헤더가 저장되는 경로를 지정합니다.
또한 다음과 같이 포함 파일을 검색할 경로를 지정합니다. -I. 지정된 경우
마지막 값이 대상으로 여러 번 사용되지만 이전 값은 모두
포함 검색 경로에 보관됩니다. 기본값으로 전혀 지정하지 않을 때,
"포함"가 사용됩니다. 이것이 상대 경로라는 점에 유의하십시오.
현재 작업 디렉토리.

이 옵션은 TEA 패키지를 생성할 때 관련이 없습니다(옵션 참조). -차 아래).

-패키지 애플리케이션의 기본 모드는 ".critcl"에 나열된 파일
명령줄을 열고 결과 캐시에 결과를 저장합니다. 기본적으로 사전 채우기
중요한 패키지를 캐시하여 이를 사용하는 데 필요한 시간을 줄입니다.
패키지.

이 옵션은 다른 모드 중 하나인 패키지 생성을 활성화합니다. 이 모드에서는
입력 파일은 평소와 같이 먼저 처리되지만 그 후에 번들로 묶입니다.
이 라이브러리를 다음과 같이 사용할 수 있도록 단일 라이브러리 및 추가 파일이 생성됩니다.
일반 Tcl 패키지.

옵션 -차, 아래 참조, 마지막 모드인 TEA 생성을 호출합니다. 두 가지 옵션이 모두 있는 경우
즉 -패키지 과 -차 마지막으로 지정된 승리가 지정됩니다.

이 모드에서 옵션 -깨끗한 과 -힘 관련이 없고 무시됩니다. 대조적으로,
옵션 -libdir 이것과 둘 다에 관련이 있습니다 -차 방법.

이 옵션이 지정되면 다음 첫 번째 파일 인수의 기본 이름
options는 생성할 패키지의 이름으로 사용됩니다. 그 연장선이라면
파일은 공유 라이브러리(".그래서"".sl"".dylib"및".DLL") 역시
입력 파일 세트에서 제거되었습니다. ㅏ ".tcl" 파일은 입력의 일부로 유지됩니다. A
확장자가 없는 단일 파일은 실제로 ".tcl" 확장자.A
확장자가 없는 파일이지만 다음의 다른 입력 파일은 이름으로 취급됩니다.
공유 라이브러리가 적절하고 입력 파일 세트에서 제거되었습니다.

예 :
=> 패키지 이름: foo
=> 입력 파일: foo.tcl
=> 패키지 이름: foo
=> 입력 파일: bar.tcl
=> 패키지 이름: foo
=> 입력 파일: foo.tcl
=> 패키지 이름: foo
=> 입력 파일: bar.tcl

-보여 주다 이 옵션을 지정하면 시스템에서 구성을 인쇄합니다.
선택한 대상 표준 출력 그런 다음 종료합니다. 대상 선택에 영향을 줄 수 있음
옵션을 통해 -표적 (아래 참조).

-모두 보이기
이 옵션을 지정하면 시스템이 선택한 전체를 인쇄합니다.
구성 파일 표준 출력 그런 다음 종료합니다. 구성 파일을 선택할 수 있습니다.
옵션을 통해 영향을 받음 -구성 (위 참조).

-표적 name
이 옵션은 빌드 대상의 기본 선택을 사용자의 선택으로 재정의합니다.
여러 번 지정하면 마지막 값이 사용됩니다. 명명된 대상이 있어야 합니다.
선택한 구성 파일에서. 사용 옵션 -대상 (아래 참조) 목록을 얻으려면
허용되는 대상. 구성 파일의 선택은 다음을 통해 영향을 받을 수 있습니다.
옵션 -구성 (위 참조).

이 옵션은 TEA 패키지를 생성할 때 관련이 없습니다(옵션 참조). -차 아래).

-대상
이 옵션을 지정하면 시스템이 알려진 모든 목록을 인쇄합니다.
선택한 구성 파일에서 대상으로 표준 출력 그런 다음 종료합니다. 의 선택
구성 파일은 옵션을 통해 영향을 받을 수 있습니다. -구성 (위 참조).

-차 옵션과 유사 -패키지, 호출된 모드가 바이너리를 생성하지 않는다는 점을 제외하고,
그러나 ".critcl" 파일, 동반 파일 및
필요한 대부분의 지원 코드가 포함된 TEA 유사 빌드 시스템(사본 포함)
critcl 패키지).

두 옵션, 즉 -패키지 과 -차 마지막으로 지정된 승리가 지정됩니다.

이 모드에서 옵션 -I, -L, -깨끗한, -힘, -은닉처, -포함디렉터리, -할 수있게하다,
-장애를 입히다및 -FOO와 함께 관련이 없고 무시됩니다. 그에 반해 옵션은 -libdir
이것과 둘 다에 관련이 있습니다 -패키지 방법.

이 옵션이 지정되면 다음 첫 번째 파일 인수의 기본 이름
options는 생성할 패키지의 이름으로 사용됩니다. 그 연장선이라면
파일은 공유 라이브러리(".그래서"".sl"".dylib"및".DLL") 역시
입력 파일 세트에서 제거되었습니다. ㅏ ".tcl" 파일은 입력의 일부로 유지됩니다. A
확장자가 없는 단일 파일은 실제로 ".tcl" 확장자.A
확장자가 없는 파일이지만 다음의 다른 입력 파일은 이름으로 취급됩니다.
공유 라이브러리가 적절하고 입력 파일 세트에서 제거되었습니다.

예 :
=> 패키지 이름: foo
=> 입력 파일: foo.tcl
=> 패키지 이름: foo
=> 입력 파일: bar.tcl
=> 패키지 이름: foo
=> 입력 파일: foo.tcl
=> 패키지 이름: foo
=> 입력 파일: bar.tcl

-이름으로 가치
이 옵션은 사용자 지정 빌드 구성 옵션의 값을 설정합니다. name 에 가치.

정보는 ".critcl" 실제 입력 파일
사용자 지정 빌드 구성 옵션을 정의하고 사용합니다. name.

이 옵션은 TEA 패키지를 생성할 때 관련이 없습니다(옵션 참조). -차 위).

PACKAGE 구조

critcl에 의해 생성된 패키지의 기본 구조는 다음과 같습니다.

+- pkgIndex.tcl
+- critcl-rt.tcl
+- license.terms(선택 사항)
|
+- tcl(선택 사항)
| +-
|
+-
+-

노트

[1] 파일 "pkgIndex.tcl"는 Tcl이 예상하는 표준 패키지 색인 파일입니다.
패키지 관리. 패키지 검색 중에 소싱되며 다음을 선언합니다.
파일과 함께 Tcl에 대한 패키지 및 이를 처리하는 방법.

[2] 파일 "critcl-rt.tcl"는 다음에서 사용하는 공통 코드를 포함하는 도우미 파일입니다.
"pkgIndex.tcl" 작업을 수행합니다.

[3] 파일 "라이선스.약관"는 선택 사항이며 ".critcl"파일을
패키지는 사용된 명령에서 생성됩니다. 크리티컬::라이센스 패키지 선언
저자 및 라이센스.

[4] 명령으로 선언된 모든 파일 크리티컬::t소스 하위 디렉토리에 저장됩니다.
"TCL".

[5] critcl에 의해 생성된 공유 라이브러리는 플랫폼별 하위
디렉토리.

전체 구조, 특히 마지막 지점을 통해 나중에 결과를 병합할 수 있습니다.
(동일한 패키지 및 버전용) 여러 대상 플랫폼을 단일 디렉토리로
상위 디렉토리를 서로 복사하기만 하면 충돌 없이 구조를 만들 수 있습니다. 그만큼
충돌할 수 있는 파일만 그리고 "TCL" 디렉토리, 이를 위해 우리는
대상 간에 동일하다는 것을 알고 있습니다. 이러한 병합의 결과는 다음과 같습니다.

+- pkgIndex.tcl
+- critcl-rt.tcl
+- license.terms(선택 사항)
|
+- tcl(선택 사항)
| +-
|
+-
| +-
+-
| +-
+-
+-

변경 위한 버전 2.1

[1] 버그 수정 크리티컬::t소스 해석된 상대 경로는
"에 상대적인 대신 현재 작업 디렉토리.critcl" 파일을 사용하여
이 유형의 다른 모든 명령과 마찬가지로 명령입니다.

[2] 고정 내부, 여러 "에 대한 정보 수집 방지".critcl" 파일을
그들 사이에 누출. 특히, 크리티컬::tk 전역 구성 옵션이 아닙니다.
더 이상.

[3] 명령 수정 크리티컬::라이센스 "컴파일 및 실행" 모드에서 null 작업이 되려면
오류를 던지는 대신.

[4] "컴파일 및 실행" 결과 캐시에 대한 critcl 응용 프로그램의 간섭을 수정했습니다.
in -패키지 완전히 분리된(및 기본적으로 임시)
해당 모드의 디렉토리입니다.

[5] "로 변경되는 버그 수정.critcl" 파일로 인해 모드에 대한 재구축이 발생하지 않았습니다.
"컴파일 및 실행". 모든 관련 API 명령은 이제 UUID 변경을 보장합니다.

[6] 백엔드 처리 버그 수정 크리티컬::디버그 여기서 컴패니언 c-소스는
ㅏ ".critcl" 파일이 디버그 옵션으로 컴파일되지 않았지만 ".critcl" 파일
였다.

[7] 버그 수정 크리티컬::디버그 모드 "all"의 인식을 막았을 때
명령에 대한 첫 번째 인수가 아닙니다.

[8] "의 버그 수정예압.c" 비 Windows 플랫폼에서 컴파일을 방지합니다.

[9] 명령 이름에서 네임스페이스 한정자를 처리할 때 발생하는 오랜 버그 수정
인수 크리티컬::cproc 과 크리티컬::명령. 이제 다음을 지정할 수 있습니다.
문제가 없는 정규화된 명령 이름입니다.

[10] 확장/재작업 크리티컬::t소스 "를 선언하는 정식 방법입니다..tcl"
컴패니언 파일은 "컴파일 및 실행" 모드에서도 가능합니다.

[11] 확장/재작업 크리티컬::t소스 "의 사용을 허용하기 위해.critcl" 자신의 파일
Tcl 컴패니언 파일.

[12] 확장 크리티컬::프레임워크 내부적으로 OS X 빌드 대상을 확인하고 무시합니다.
그렇지 않은 경우 선언.

[13] 확장 크리티컬::실패 "에서 두 번 이상 호출할 수 있습니다..critcl" 파일입니다.
첫 번째 호출은 빌드가 아직 완료되지 않은 경우 강제로 결과를 얻습니다. 더 나아가
호출은 첫 번째 호출의 캐시된 결과를 반환합니다.

[14] 다음을 결정하는 코드에서 환경 변수 CC의 처리를 확장했습니다.
컴파일러, 컴파일러 파일에 대한 경로를 처리(즉, 제거)하는 데 사용할 컴파일러
확장 및 컴파일러 자체 뒤에 지정되는 컴파일러 옵션만 남음
컴파일러의 기본 이름.

[15] 경로를 인쇄하기 위해 미리 로드된 라이브러리 검색을 처리하는 코드를 확장했습니다.
검색 실패를 쉽게 디버깅할 수 있습니다.

[16] 새 명령 크리티컬::tcl Tcl의 버전을 최소한으로 선언하는 데 사용할 수 있습니다.
"를 빌드하고 실행하는 데 필요합니다..critcl" 파일 및 패키지. 그렇지 않은 경우 기본값은 8.4입니다.
선언했다. Tcl 8.4, 8.5,
및 8.6.

[17] 새 명령 크리티컬::로드 "의 빌드 및 로드를 강제합니다..critcl" 파일입니다. 이것은
critcl의 기본 lazy-build-&-load-on-demand 체계를 재정의하는 공식적인 방법
모드 "컴파일 및 실행"용.

주의 사항 사용 후 크리티컬::로드 / 크리티컬::실패 안에 ".critcl" 파일이 아니다
더 이상 해당 파일에서 critcl 명령을 사용할 수 있습니다. 이렇게 하면 오류가 발생합니다.

[18] 사용할 '#line' pragma 생성 확장 정보 액자 (가능한 경우)
C 컴파일러에 정확한 줄 번호를 ".critcl"에 대한 파일
경고 및 오류 보고.

[19] 확장 크리티컬::체크 디버깅 빌드 타임 검사에 도움이 되는 로깅
환경과 레이블 지정을 제공하는 추가 선택적 인수입니다.

[20] 새로운 명령어 추가 크리티컬::체크링크 환경을 확인하려고 할 뿐만 아니라
코드 컴파일을 통해 뿐만 아니라 연결 가능성도 있습니다.

[21] 새로운 명령어 추가 크리티컬::msg 명령과 같은 메시징용 크리티컬::오류 입니다
오류 보고. 마찬가지로 이것은 패키지 사용자가 할 수 있는 후크입니다.
우세하다. 모드에서 사용되는 기본 구현 편집하다 & 운영 아무것도 하지 않습니다. 그만큼
모드 구현 생성 꾸러미 메시지를 stdout에 인쇄합니다.

계획된 사용은 다음에 의해 결정된 결과 보고를 위한 것입니다. 크리티컬::체크 과
크리티컬::체크링크 빌드하는 동안 무언가 잘못되었을 때 디버깅을 돕기 위해
수표로.

[22] 인수 처리 내부를 노출 크리티컬::프로시저 고급 사용을 위해
사용자. 새로운 명령은

[1] critcl::arnames

[2] critcl::argcnames

[3] critcl::argc서명

[4] critcl::argvardecls

[5] critcl::argconversion

섹션을 참조하십시오 Advnaced Embedded C 암호 의 크리티컬 패키지 설명서
세부.

[23] 가로채기 위해 critcl 패키지 확장 꾸러미 제공 그리고 파일을 기록 ->
패키지 이름 매핑. 또한 기타 내부 변경으로 이제 네임스페이스 사용이 허용됩니다.
여전히 적절한 경로 이름과 init 함수를 사용하면서 패키지 이름을 지정합니다.

[24] 사용하지 않는 명령 삭제 크리티컬::최적화 과 크리티컬::포함.

[25] 떨어졌다 -lib critcl 응용 프로그램의 모드입니다.

[26] Tcl 8.3 이전 버전에 대한 지원이 중단되었습니다.

변경 위한 버전 3

[1] 명령 크리티컬::플랫폼 버전 2.1에서 더 이상 사용되지 않으며 다음으로 대체되었습니다.
critcl::대상 플랫폼, 그러나 호환성을 위해 유지됩니다. 이제 제거되었습니다.

[2] 명령 크리티컬::컴파일됨 의미 체계가 있는 버전 2.1에서 유지되었습니다.
호환성을 위해 그것과 모순됩니다. 이 모순이 제거되었으며,
명령의 가시적 의미를 해당 이름과 일치하도록 변경합니다.

[3] 버전 3으로의 변경은 두 개의 비호환 가시성 때문에 필요하게 되었습니다.
위의 변경 사항.

[4] 새 옵션을 처리하는 코드로 애플리케이션 패키지 확장 -차. 지정
이 옵션은 critcl이 TEA 패키지를 생성하는 특수 모드를 호출합니다.
디렉토리 계층에 대한 입력 및 이를 제공하는 지원 파일 TEA-
유사 빌드 시스템.

이 새로운 옵션과 -패키지, 서로를 제외하십시오. 둘 다 지정된 경우 마지막으로 사용한
옵션이 우선합니다.

생성된 패키지 디렉토리 계층 구조는 대부분 자체 포함되어 있지만 완전하지는 않습니다.
작동하는 Tcl 설치뿐만 아니라 작동하는 설치도 필요합니다.
패키지의 md5 과 명령줄. 이 두 가지 모두 티클립 묶음.
필수는 아니지만 설치할 수 있는 패키지를 설치하는 것이 좋습니다.
md5의 작업을 가속화합니다. 암호키트, tcllibc및 TRF.

[5] 새 명령으로 critcl 패키지 확장 크리티컬::스캔 로 가는 길을 택하다
".critcl" 파일을 정적으로 스캔하고 라이센스, 버전, 목록을 반환합니다.
컴패니언 파일, 가져온 API 목록 및 개발자 지정 사용자 정의 목록
구성 옵션. 이 데이터는 설명된 TEA 포장의 기초입니다.
위.

이것은 정적 인 주사. 다른 빌드 모드는 다음을 실행할 수 있는(반드시) 반면
".critcl" 어셈블된 C 코드와 관련하여 파일을 작성하고 플랫폼별 결정을 내립니다.
컴패니언 파일 등 TEA 랩 모드는 플랫폼을 만들 수 있는 위치에 있지 않습니다.
특정 결정. 필요할 수 있는 모든 것을 포장해야 합니다.
실제로 건축할 때 따라서 정적 스캔. 그러나 이것은 자체 세트를 가지고 있습니다.
문제, 즉 동반자의 동적 구성을 파악할 수 없음
적어도 그 자체로는 파일 경로. 따라서:

[6] critcl 기반 패키지에서 사용하는 API를 다음 명령으로 확장했습니다. 크리티컬::소유. 동안
이 명령은 정적 스캐너가 설명한 일반 빌드 모드에서 무시됩니다.
위의 인수는 래핑해야 하는 컴패니언 파일의 이름으로 사용됩니다.
TEA 패키지에 들어가고 그렇지 않으면 스캐너에서 알아낼 수 없습니다.
동적 경로 때문에 크리티컬::t소스, 크리티컬::c소스, 소싱 받기
직접 또는 단순히 부속 데이터 파일이 됩니다.

[7] critcl 기반 패키지에서 사용하는 API를 다음 명령으로 확장했습니다. 크리티컬::api 위한
스텁 테이블 관리(사용 및/또는 선언 및 내보내기).

섹션을 참조하십시오 스텁 작업대 의 크리티컬 패키지 설명서
세부.

[8] critcl 기반 패키지에서 사용하는 API를 다음 명령으로 확장했습니다. 크리티컬::사용자 구성
개발자가 지정한 사용자 지정 구성 옵션 관리를 위해
사용 및/또는 선언.

섹션을 참조하십시오 관습 짓다 구성 의 크리티컬 패키지 문서
자세한 내용은.

[9] 다음 명령으로 critcl 기반 패키지에서 사용하는 API를 확장했습니다.
크리티컬::설명, 크리티컬::요약, 크리티컬::제목, 크리티컬::메타및
크리티컬::빌드 요구 사항 TEApot 메타 데이터 선언
패키지.

섹션을 참조하십시오 묶음 메타 Data 의 크리티컬 패키지 설명서
세부.

변경 위한 버전 3.0.1

[1] 전반적인 버그 수정. 상세히:

[2] Tcl 버전 요구 사항의 고정 기록. 패키지 이름 및 버전 유지
함께, 깨지지 않는 생성된 메타 데이터 및 생성된 패키지 로드 명령.

[3] 빌드 스크립트 수정: TEA를 설치하거나 래핑할 때 누락된 항목을 생성합니다.
디렉토리

[4] 창이 열릴 때 응용 프로그램을 올바르게 종료하도록 빌드 스크립트를 수정했습니다.
GUI는 (X) 버튼을 통해 닫힙니다.

[5] 기본 빌드 스크립트에 포함된 8.5-ism(open wb)을 제거했습니다.

[6] 예제 빌드 스크립트를 수정하여 서로 다른 출력을 분리했습니다.
빈 줄을 추가하여 예제(및 패키지).

[7] stack::c 예제 버그 수정: 컴패니언 파일에서 사용할 API 선언을 포함합니다.

[8] 문서 확장: C의 작동 설치에 대한 필요성을 언급했습니다.
컴파일러.

[9] 사용된 매니페스트 파일을 처리하기 위해 Windows 대상 정의 및 코드를 확장했습니다.
최신 MS 개발 환경에 의해. 이 코드는 둘 다 처리합니다.
가능성, 매니페스트를 사용하는 환경 및 (오래된) 없는 환경.

[10] 필요를 자동 감지하도록 Windows 64비트 대상 정의 및 코드를 확장했습니다.
도우미 라이브러리 "bufferoverflowU.lib" 및 컴파일 및 링크 재구성
적절하게 명령합니다. 라이브러리가 있을 때 링크되어야 한다고 가정합니다.
라이브러리가 있지만 아직 필요하지 않은 경우에는 문제가 되지 않습니다. 불필요합니다.
환경 변수 LIB로 지정된 경로에서 라이브러리를 검색합니다.

변경 위한 버전 3.0.2

[1] auto_index에 넣은 명령이 실행되지 않는 컴파일 및 실행 모드의 문제 수정
Tcl의 [unknown] 명령에 의해 발견되었습니다.

[2] 배열 키 불일치로 인해 클라이언트 데이터 사용이 중단되고
절차. Jos DeCoster가 패치와 함께 보고했습니다.

[3] 명령줄 옵션 구현 -L, 옵션과 동일 -I, 라이브러리 전용
검색 경로.

[4] github 문제 5 및 8을 수정했습니다. 누락된 변수 ::errorInfo를 해결했습니다. 그것
항상 있어야 하지만 Tcl의 개정판이 있는 것 같습니다.
이 가정을 위반합니다.

변경 위한 버전 3.0.3

[1] 예제 build.tcl 스크립트에 대한 github 문제 5 및 8을 수정했습니다. 주변에서 작업
누락된 변수 ::errorInfo. 항상 존재해야 하지만 존재하는 것처럼 보입니다.
이 가정을 위반하는 Tcl의 개정판.

변경 위한 버전 3.0.4

[1] 들어오는 코드를 읽을 때 패키지의 초기 이름 생성을 수정했습니다.
stdin이고 적절한 경로가 없습니다.

[2] github 문제 11 수정. 이제 Windows에서 -L 대신 /LIBPATH 사용(libinclude
구성 설정).

[3] -l 옵션의 -l:path 형식을 처리하기 위해 critcl을 확장했습니다. GNU ld 2.22+가 이것을 처리합니다.
경로를 그대로 검색하여. 일반 -l로 정적 라이브러리를 지정할 때 좋습니다.
정적보다 우선적으로 공유 라이브러리를 찾습니다. critcl은 다음과 같이 지금 처리합니다.
이전 GNU ld는 이를 이해하지 못하며 다양한 벤더별 링커도 이해하지 못합니다.

[4] github 문제 #12 수정. Critcl은 이제 사용 중인 MSVC의 버전을 결정하고 사용합니다.
다양한 링크 디버그 옵션 사이를 전환합니다. 취급 간소화
bufferoverflowU.lib도 동일한 메커니즘을 사용하고 두 가지를 축소합니다.
구성 섹션을 다시 하나로 만들었습니다.

[5] 생성된 C 코드에 #line pragma 삽입을 재작업하여
다양한 컴파일러에 의해 부과된 줄 번호 인수에 대한 제한, 그리고 더 많은
정확한.

[6] 수정된 인수 처리. -libdir 옵션은 이제 해당 인수에 대해 -L도 의미합니다.

[7] -show 옵션의 확장 처리(critcl::쇼구성)의 경로를 나열하려면
데이터가 오는 구성 파일. 디버깅 구성에 적합
처리.

[8] 포함된 문서를 재생성하기 위해 대상으로 빌드 스크립트를 확장했습니다.
및 다이어그램을 만들고 릴리스를 생성합니다.

변경 위한 버전 3.0.5

[1] C 코드를 지정할 때 트리거되는 #line pragma에 대한 새 코드의 버그 수정
선행 공백없이.

[2] 라이센스, 소스 검색,
설치 프로그램 및 개발자 가이드.

변경 위한 버전 3.0.6

[1] github 문제 10 수정. critcl 애플리케이션이 이제 적절한 종료 코드를 제공합니다. (1)
항상 성공(상태 0)을 나타내는 대신 빌드 실패 시.

[2] github 문제 13을 수정했습니다. 릴리스 빌드에 대한 bufferoverflowU.lib 처리가 변경되었습니다.
디버그 빌드 처리와 일치하지 않습니다. 이제 동일하게 처리됩니다.
(조건부) 두 경우 모두.

[3] 문서 정리, 주로 설치 안내서 및 README.md에 표시됨
github

변경 위한 버전 3.0.7

[1]에 의해 생성된 코드 수정 크리티컬::c++명령. 방출된 코드는
정적 문자열 테이블 Tcl_GetIndexFromObj, 계약 위반,
테이블에 고정 주소가 있어야 합니다. 이것은 메모리 스매시를 기다리고 있었다
일어나다. 일반적인 문제에 대해 알려주신 Brian Griffin에게 감사드립니다.

변경 위한 버전 3.1

[1] 새로운 상위 패키지 추가 크리티컬::iassoc.

이 패키지는 데이터를 인터프리터와 연결하는 코드 생성을 단순화합니다.
Tcl을 통해 Tcl_(Get|Set)AssocData() 아피스. 사용자는 자신의 데이터에 집중할 수 있습니다.
이를 지원하는 데 필요한 모든 상용구 C 코드는 패키지에서 생성됩니다.

이 패키지는 코어에 추가된 몇 가지 새로운 기능을 사용합니다. 크리티컬
패키지는 아래를 참조하십시오.

[2] 상위 패키지 추가 크리티컬::클래스.

이 패키지는 클래스 및 인스턴스를 사용하여 C 레벨 객체 생성을 단순화합니다.
명령. 사용자는 클래스 및 인스턴스 변수로 클래스 정의를 작성할 수 있습니다.
-TclOO 클래스와 유사한 메소드, 필요한 모든 상용구 C 코드 포함
패키지에서 생성된 이를 지원합니다.

이 패키지는 코어에 추가된 몇 가지 새로운 기능을 사용합니다. 크리티컬
패키지는 아래를 참조하십시오.

[3] TEApot 메타데이터를 처리하기 위해 API를 확장했습니다. 명령을 추가했습니다 크리티컬::메타? 에
저장된 정보를 조회합니다. 현재 예상되는 주요 용도는
구성된 이름에 사용하기 위한 유틸리티 명령으로 현재 패키지의 이름. 이것
패키지의 정적 스캔으로 인해 특정 정보를 항상 사용할 수 있습니다.
첫 번째 critcl 명령 실행 시 파일.

새로운 패키지 크리티컬::iassoc 과 크리티컬::클래스 (위 참조) 사용자입니다.
명령.

[4] 명령으로 API 확장, 크리티컬::name2c, 변환 과정 노출
Tcl 이름을 기본 이름, 네임스페이스 및 C 네임스페이스로 변환합니다. 이를 통해 더 높은 수준의
동일한 유형의 C 식별자를 생성하는 코드 생성기 크리티컬 자체.

새로운 패키지 크리티컬::클래스 (위 참조)는 이 명령의 사용자입니다.

[5] 명령으로 API 확장, 크리티컬::소스, critcl 명령 실행
현재 파일의 컨텍스트에서 별도의 파일. 이를 통해 보다 쉽게 ​​관리할 수 있습니다.
사용자가 더 쉽게 분할할 수 있으므로 더 큰 코드 본문
여러 패키지를 생성하지 않고 더 작은 청크를 소화합니다.

[6] 이전 항목과 관련하여 컬렉션을 전환하는 명령으로 API를 확장했습니다.
생성된 C 코드를 메모리에 저장합니다. 이렇게 하면 다음에 대한 명령을 더 쉽게 사용할 수 있습니다.
상위 수준 코드 생성기에 내장된 C 코드.

섹션 참조 많은: 다양성 제공된 명령에 대한 자세한 내용은

새로운 패키지 크리티컬::클래스 (위 참조)는 이러한 시설의 사용자입니다.

[7] 개발자가 적절한 C를 생성하는 데 도움이 되는 명령으로 API를 확장했습니다.
#선 지시. 이를 통해 더 높은 수준의 코드 생성기가 생성하고 삽입할 수 있습니다.
코드의 컴파일 오류가 적절하게 발생하는지 확인하는 자체 지시문
귀속.

섹션 참조 많은: 장소 구축 제공된 명령에 대한 자세한 내용은

새로운 패키지 크리티컬::iassoc 과 크리티컬::클래스 (위 참조)는 이들의 사용자입니다.
시설.

[8] 사용자가 사용자 지정 인수를 정의할 수 있는 기능을 제공하는 명령으로 API를 확장했습니다.
및 결과 유형 ::크리티컬::cproc.

섹션 참조 많은: 확장 cproc 제공된 명령에 대한 자세한 내용은

변경 위한 버전 3.1.1

[1] 전반적인 버그 수정. 상세히:

[2]에 대한 wrong#args 오류 생성 수정 크리티컬::cproc 파생 코드
(크리티컬::클래스 cproc 기반 방법). 인수가 없으면 NULL을 사용하고
오프셋을 고려합니다.

[3] 다음에 의해 패키지 이름 처리가 수정되었습니다. 크리티컬::클래스. 포함할 수 있음을 잊어버렸습니다.
네임스페이스 구분자. 버전 1.0.1로 충돌했습니다.

[4] 확장 크리티컬::클래스 명확성을 위해 인스턴스 생성 시 생성된 오류 메시지.
버전 1.0.2로 충돌했습니다.

변경 위한 버전 3.1.2

[1] 향상. 상세히:

[2] 확장 크리티컬::cproc 선택적 인수를 제한된 방식으로 처리할 수 있습니다.
이는 자동으로 사용할 수 있습니다. 크리티컬::클래스 cproc 기반 방법도 마찬가지입니다.

[3] 버그 수정 할당하다 Tcl 8.4용 에뮬레이션. 사용하지 않는 변수를
빈 문자열. 에뮬레이션 패키지의 범프 버전 l할당84 1.0.1합니다.

변경 위한 버전 3.1.3

[1] 향상. 상세히:

[2] 카운트된 문자열인 "Pascal String"에 대한 새 인수 유형 "pstring"이 추가되었습니다.
문자열 포인터와 문자열 길이의 조합.

[3] 새로운 방법 추가 critcl::argtype지원 과 ::critcl::인수지원 정의하고 사용하기 위해
인수 유형에 대한 추가 지원 코드, 여기서는 위의 "pstring"에서 사용하여
필요한 구조를 정의합니다.

[4] 패키지의 세미 버그 수정 크리티컬::클래스 과 크리티컬::iassoc. AS용 프래그마
템플릿 파일이 패키지의 일부가 되도록 메타 데이터 스캐너.
버전은 각각 1.0.4 및 1.0.1로 변경되었습니다.

변경 위한 버전 3.1.4

[1] 패키지의 버그 수정 크리티컬::클래스. 다음과 같은 경우 클래스 구조에 더미 필드를 생성합니다.
클래스에는 클래스 변수가 없습니다. 이 변경이 없으면 구조가 비어 있을 것입니다.
많은 컴파일러가 이러한 형식을 처리할 수 없습니다.

[2] win64 구성을 깨뜨린 오타를 수정했습니다.

[3] 명령 문서의 오타인 문제 #16 수정 크리티컬::클래스.

변경 위한 버전 3.1.5

[1] 문제 #19 수정. MSVC 버전 번호를 추출하는 정규 표현식을 만들었습니다.
독일어 시스템에서 작동하도록 하는 것이 더 일반적입니다. 이것은
다른 Windows 로케일에 대해 나중에 다시 방문했습니다.

[2] 문제 #20 수정. 적어도 유닉스 에뮬레이션에서 Windows에서 옵션 차 작업을 만들었습니다.
msys/mingw와 같은 환경.

변경 위한 버전 3.1.6

[1] 문제 #21 수정. 스텁 테이블 포인터 변수의 다중 정의가
지금까지 본 모든 C 링커에 대해 확인했습니다. C++ 링커는 이것을 전혀 좋아하지 않았습니다.
이 변수 집합이 한 번만 생성되도록 코드를 재작업했습니다.
조립할 모든 조각을 감싸는 포장지.

[2] 고정된 문제 #22, 의 명령 식별자 인수 처리
크리티컬::명령, 크리티컬::cproc및 크리티컬::cdata. 이제 모든 Tcl을 올바르게 허용합니다.
식별자에서 적절한 내부 C 식별자를 생성합니다.

이것의 일부로 명령의 서명 크리티컬::name2c 변경되었습니다. 지금 명령
XNUMX개가 아닌 XNUMX개의 값 목록을 제공합니다. 새 값이 에 추가되었습니다.
끝.

패키지 구현을 추가로 조정했습니다. 크리티컬::클래스, 사용자
크리티컬::name2c. 이 패키지는 현재 버전 1.0.6이며 critcl 3.1.6이 필요합니다.

마지막으로 잘못된 옵션 처리를 수정했습니다. -c이름 in 크리티컬::명령및
크리티컬::cproc.

[3] 문제 #23 수정.

변경 위한 버전 3.1.7

[1] 문제 #24 수정. 다음에서 발견된 컴파일러 경고를 추출하고 무조건 표시합니다.
빌드 로그. 빌드를 유발하지 않는 동안 사용자가 경고를 놓치지 않도록 방지합니다.
실패해도 여전히 문제가 있음을 나타낼 수 있습니다.

[2] 새로운 기능. 출력 후크. 모든 비메시징 사용자 출력은 이제 다음을 통해 라우팅됩니다.
명령 크리티컬::인쇄, 사용자는 critcl을 사용할 때 이를 재정의할 수 있습니다.
패키지로서의 애플리케이션.

[3] Ashok P. Nadkarni의 새로운 기능. 플랫폼 구성은 다음에서 값을 상속할 수 있습니다.
이전에 정의된 구성.

변경 위한 버전 3.1.8

[1] Tcl 8.4용으로 생성된 패키지 색인 문제가 수정되었습니다. 명령 목록에 참여
개행 문자가 아닌 세미콜론으로.

[2] 수정하는 동안 고려하지 않은 사용 사례를 가져온 문제 #26을 수정했습니다.
버그 #21(비판 3.1.6 참조).

변경 위한 버전 3.1.9

[1] 문제 #27 수정. 다양한 대체 Linux 및
OS X 대상.

[2] 문제 #28 수정. linux-{32,64}-*에서 연결하기 위해 누락된 -mXX 플래그를 추가했습니다.
목표.

[3] 문제 #29 수정. 처리에서 원시 "cheaders" 정보의 사용을 대체했습니다.
"cdefines"에서 파생된 적절한 include 지시문을 포함합니다.

[4] Andrew Shadura가 거부한 풀 요청 #30 뒤에 있는 문제를 수정했습니다. 동적으로
Tcl 헤더 파일에서 스텁 변수 선언을 추출하고 생성
패키지 코드에서 사용할 일치하는 변수 정의. 생성된 코드는
이제 critcl의 자체 복사본이 있는 경우에도 항상 헤더와 일치해야 합니다.
시스템 헤더로 대체됩니다.

[5] 문제 #31 수정. Andrew Shadura가 승인한 패치, 변경 사항(의견) 포함,
critcl을 OS 패키지 시스템과 더 쉽게 통합하여 critcl의 사본을 대체합니다.
자체 Tcl 헤더.

[6] 문제 #32 수정. Andrew Shadura의 풀 리퀘스트를 병합했습니다. 다양한 오타
문서 및 의견.

[7] 문제 #33 수정. 점으로 시작하는 파일을 더 잘 처리합니다.

작가

장 클로드 위플러, 스티브 랜더스, 안드레아스 쿠프리스

onworks.net 서비스를 사용하여 온라인에서 critcl 사용