%3F.png)
https://www.uber.com/blog/bootstrapping-ubers-infrastruct-on-arm64-with-zig/설명하다:
호스트는 바이너리가 컴파일되는 시스템입니다. 대상은 바이너리가 실행될 머신입니다. 네이티브 컴파일에서는 호스트와 대상이 동일한 플랫폼입니다(즉, 운영 체제, 프로세서 아키텍처 및 공유 라이브러리가 동일함).
https://nixos.org/manual/nixpkgs/stable/#ssec-stdenv-dependent-reference설명하다:
종속성은 세 가지 축을 따라 분류될 수 있습니다.새로운 파생상품과 관련된 호스트 및 타겟 플랫폼, 그리고 전송 여부. 플랫폼 차이는 크로스 컴파일로 인해 발생합니다. 각 플랫폼이 구체적으로 무엇을 의미하는지 알아보려면 크로스 컴파일을 참조하세요. [1] 그러나 크로스 컴파일이 아니더라도 플랫폼은 런타임에 종속성이 필요한지 아니면 빌드 타임에 필요한지 여부를 의미하며, 이는 크로스 컴파일 외부에서 많은 의미가 있는 개념입니다. 기본적으로 런타임/빌드 시간 구별은 명확성을 위한 힌트일 뿐이지만 strictDeps를 설정하면 기본적으로 기본적으로 적용됩니다.
위에서 언급한 종속성을 포함한 PATH 확장은 관련 플랫폼에 따라서만 이루어집니다.이 프로세스는 호스트 플랫폼이 새로 포크된 빌드 플랫폼과 일치하는 종속성, 즉 새 포크가 빌드될 플랫폼에서 실행되는 종속성에 대해서만 수행됩니다.[2] 이러한 각 종속성에 대해 dep/bin(있는 경우)이 PATH 환경 변수에 추가됩니다.
다른 전이적(비직접) 다운스트림 종속성도 직접 종속성으로 요구하는 경우 종속성이 전파된다고 합니다. [삼]
주의하는 것이 중요합니다이전처럼 종속성이 반드시 전파되는 것은 아닙니다.,대신 플랫폼 규칙이 일관되게 유지되도록 그에 따라 순서를 지정하세요..종속성 전파에 대한 정확한 규칙을 결정하기 위해 먼저 각 종속성에 여러 삼항 숫자(빌드의 경우 -1, 호스트의 경우 0, 대상의 경우 1)를 할당하여 호스트와 대상을 캡처하는 종속성 유형을 나타냅니다. 플랫폼 상황은 각각에 따라 다릅니다. 파생된 호스트와 대상 플랫폼의 "오프셋"입니다.아래 표에는 사용 가능한 다양한 조합이 요약되어 있습니다....
첫 번째 참조는 패키지의 호스트 및 대상 플랫폼을 패키지가 빌드되고 실행되는 플랫폼으로 정의합니다.
그런데 두 번째 문장을 읽어보니 이해가 안 됐어요.
이 프로세스는 호스트 플랫폼이 새로 포크된 빌드 플랫폼과 일치하는 종속성, 즉 새 포크가 빌드될 플랫폼에서 실행되는 종속성에 대해서만 수행됩니다.
이는 종속성의 호스트 플랫폼이 실행되는 위치로 정의된다는 것을 의미합니까? 그리고 새로 파생된 빌드 플랫폼이 빌드되는 곳인가요?
호스팅 플랫폼과 빌드 플랫폼은 동일한 개념인가요? 그렇다면 두 번째 문장이 왜 이들을 구별합니까?
감사해요.
답변1
호스트 B(플랫폼 유형 A)가 플랫폼 유형 Y에 대한 소프트웨어 X를 구축하고 있다고 가정합니다.
이제 B는호스트 구축A는 될 것이다식물 형태 확립. 이는 빌드 프로젝트의 모든 하위 부분에 해당됩니다.
소프트웨어 X에는 두 가지 유형의 종속성이 있을 수 있습니다.런타임 종속성그리고빌드 시간 종속성. 그러나 빌드 시간 종속성은 두 가지 하위 범주로 더 나눌 수 있습니다.
- 빌드 프로세스의 일부로 빌드 호스트에서 실행해야 하는 것, 즉 소스 코드 전처리기 및 유사한 도구입니다. 이는 플랫폼 A에서 실행하기에 적합해야 합니다.
- 정적으로 연결될 코드 베이스 또는 최종 소프트웨어 패키지에 병합될 데이터와 같이 소프트웨어 X의 일부가 될 것입니다. 실행 가능한 코드가 이 범주에 속하는 경우 플랫폼 Y에서 실행하기에 적합해야 합니다. 이 하위 클래스의 일부 콘텐츠(예: 특정 라이브러리 헤더 파일 및 기타 데이터 항목)는 실제로 플랫폼 독립적일 수 있습니다.
플랫폼 A가 플랫폼 Y와 같을 때 두 하위 유형은 모두 같은 방식으로 해결될 수 있습니다. 즉, 종속성 트리를 구축하고 리프에서 시작하여 루트까지 작업하면 됩니다.
그러나 A가 Y와 같지 않으면 각 빌드 시간 종속성이 속한 하위 유형도 추적해야 합니다.
이제 각 빌드 시간 종속성은 자체 종속성을 가질 수 있습니다. 따라서 빌더는 소프트웨어를 빌드하기 위해 체인이 플랫폼 A를 위한 또 다른 도구 T2를 빌드하고 궁극적으로 소프트웨어 X를 빌드하는 플랫폼 A용 빌드 도구 T3으로 연결된다는 것을 알 수 있습니다.
빌드 시간 종속성의 두 번째 하위 클래스에는 교차 빌드가 필요합니다. 소프트웨어 X에 정적 라이브러리 L이 필요한 경우 빌드 호스트는 먼저 플랫폼 유형 Y에 대한 L 버전을 얻거나 빌드해야 합니다. 그러나 라이브러리 L에는 고유한 빌드 시간 종속성 세트가 있을 수 있습니다.두 가지 하위 유형: 플랫폼 Y용 라이브러리 L을 빌드하려면 빌드 호스트는 먼저 자체(플랫폼 A)를 위한 도구 T2와 라이브러리 L의 일부로 사용될 라이브러리 L2를 빌드해야 할 수 있으므로 플랫폼 Y용 L2도 빌드해야 합니다. .
자동화된 빌드 프로세스는 이러한 모든 종속성을 추적해야 합니다.임의의 깊이에 대한 각 반복. 이상적으로는 전체 빌드의 일부인 여러 소프트웨어 구성 요소를 빌드하는 데 특정 도구 T가 필요한 경우 해당 도구를 필요로 하는 모든 소프트웨어 구성 요소가 빌드될 때까지 한 번만 빌드하고 유지해야 한다는 점도 파악해야 합니다.
따라서 자동화된 빌더는 최종적으로 소프트웨어 X가 빌드될 수 있을 때까지 먼저 빌드 시간 종속성을 하나씩 빌드합니다. 각 개별 구성 요소 빌드 작업에는호스트 플랫폼하나와 하나대상 플랫폼빌드 타임 종속성의 하위 클래스에 따라 A 또는 Y입니다.
일단 소프트웨어 즉, 이 특정 소프트웨어 X 빌드 인스턴스는호스트 구축밴드대상 플랫폼와이.
이것식물 형태 확립(A) 특정 아키텍처에서 특정 도구를 사용할 때만 발생하는 빌드 오류를 추적해야 하는 경우가 아니면 이 시점에서는 일반적으로 중요하지 않습니다.
소프트웨어 프로젝트에서 문서는 일반적으로 최대 하나의 크로스 빌드 단계를 염두에 두고 작성됩니다.호스트 플랫폼동등하다식물 형태 확립: 둘 다 실행 파일이 빌드된/빌드되는 중/빌드될 플랫폼을 참조하며,대상 플랫폼빌드 중인 실행 파일이 실행될 플랫폼을 나타냅니다.
실행 파일을 구축한 후에는 실행 파일이 어떻게 구축되었는지에 대한 생각을 멈추고 실행 파일로 무엇을 할 수 있는지 생각하기 시작할 수 있습니다. 실행 파일이 크로스 컴파일러인 경우 호스트 및 대상 플랫폼 용어는 다음 단계에서 재활용됩니다.
- 크로스 컴파일러가 구축된 플랫폼은 이제 역사적인 세부 사항일 뿐이며 구체적인 이름이 없습니다.
- 새로운 크로스 컴파일러가 실행될 플랫폼은 이제 호출됩니다.호스트 플랫폼
- 새로운 크로스 컴파일러가 실행 파일을 생성할 플랫폼은 다음과 같습니다.대상 플랫폼
크로스 컴파일 크로스 컴파일러의 경우 "궁극적" 대상 플랫폼에 대해 널리 사용되는 업계 표준 용어는 없다고 생각합니다.
그러나 Nixpkgs 빌드 시스템은 크로스 컴파일러를 사용하여 크로스 컴파일 상황을 처리할 준비가 되어 있으므로Nixpkgs에 대해 구체적으로 이야기할 때,그들은 다음과 같이 다양한 플랫폼 용어를 지정합니다.:
- 식물 형태 확립= 빌드/빌드/빌드되는 실행 파일이 빌드될 플랫폼
- 호스트 플랫폼= 빌드 중인 실행 파일이 실행될 플랫폼
- 대상 플랫폼= 실행 가능한 코드를 생성하는 항목에만 적용됩니다. 빌드되는 실행 파일이 최종적으로 빌드되는 플랫폼입니다.