토파즈에는 검사되는 소스 언어 하나가 있고 실행 경로와 배포 경로는 여럿입니다. 완성한 프로그램을 어느 환경이 소유할지 보고 경로를 선택합니다.
제품에 맞춰 선택하기
- 개발 중 인터프리터에서 직접 실행하려면
topaz run을 사용합니다. - 플랫폼 전용 실행 파일이 필요하면 네이티브
build를 사용합니다. - Python 3.11 이상에서
.tpz소스와 토파즈 CLI 없이 실행할 생성 번들이 필요하면--target python을 사용합니다. - 기존 ES 모듈 호스트가 선택한 토파즈 내보내기를 호출한다면
--target web을 사용합니다. - 그 호스트에 생성된 Worker 통신 계층이 필요하면
--target web-worker를 사용합니다. - 브라우저 생명주기와 UI를 토파즈가 소유한다면 패키지 대상
web-app을 사용합니다. - 제한형 HTTP/1.1 핸들러 하나가 필요하면 패키지 대상
http-service를 사용합니다.
Raw Web과 Worker는 WASM 제품입니다. 관리형 Web 애플리케이션은 같은 검사형 Web 연결 계층을 완전한 정적 제품 안에 담아 제공합니다.
topaz run main.tpz
topaz build main.tpz --out-dir native-product
topaz build --target python --root my-app --locked --out-dir python-product
topaz build main.tpz --target web --out-dir web-product
topaz build main.tpz --target web-worker --out-dir worker-product
web-app과 http-service는 topaz.toml의 [build].target으로 선택하는
패키지 전용 대상입니다.
대상과 낮추기는 서로 다른 선택
--target은 제품을 선택합니다. --backend native는 Rust 기반 제품 안에서
선택할 수 있는 낮추기 전략입니다. 조건을 만족하는 스칼라 작업과 제한형
Bytes, ByteBuffer 연산을 먼저 시도합니다. 지원하지 않는 모양은 일반 박싱
경로에 그대로 남깁니다. 이 옵션으로 Python을 네이티브로 만들거나 Web 제품을
다른 대상으로 바꿀 수는 없습니다.
이 선택이 중요하면 검사형 native emit 또는 build에
--native-report-json <path>를 추가할 수 있습니다. 보고서는 함수마다 native,
hybrid, boxed 가운데 무엇을 골랐는지 기록합니다. 제품 바이트는 바뀌지 않습니다.
대상 경계에서 명확히 실패하기
대상들은 파싱, 모듈 해석, 정적 검사를 함께 씁니다. 그렇다고 호스트에 의존하는 모든 연산을 조건 없이 지원한다고 약속하지는 않습니다. 선택한 대상이 어떤 연산을 보존할 수 없으면 제품을 쓰기 전에 생성 오류를 냅니다. 오류에는 소스 위치가 들어갑니다.
예를 들어 결정적인 fixed-Huffman DEFLATE, 고정 zlib, RS(255,223) 보호는
인터프리터, 생성 Rust, Raw Web, Worker, 플레이그라운드에서 사용할 수 있습니다.
생성 Python은 산출물을 만들기 전에 이를 거부합니다. Hash.crc32는 Python에서도
사용할 수 있습니다.
동시 작업의 실행 순서는 의도적으로 정해 두지 않습니다. 특정 백엔드가 고른 인터리빙에 기대면 안 됩니다.
Rust, Python, LIT 경계
생성 Rust와 Python은 배포 산출물입니다. 여기서 토파즈 문법이 늘어나지는 않습니다. 손으로 고치라고 안정성을 보장한 API도 아닙니다. 각 전용 페이지가 필수 조건, 런타임 파일, 명시적 예외를 같은 구조로 설명합니다.
LIT는 Lispex 통합과 도그푸딩을 위한 제한된 경계입니다. 토파즈로 작성한 인터프리터 소스 하나를 여러 토파즈 경로에서 실행합니다. 출하되는 백엔드는 아니며 전체 언어 동등성을 증명하지도 않습니다.