Ninja: 상대 subninja 경로가 확인되지 않음

모든 경로는 subninja 라인이 포함된 파일이 아니라 빌드 디렉토리에 상대적입니다.

하지만 의미가 없습니다. 이는 생성기가 파일 앞에 접두사를 추가하는 어떤 방법을 _all__ 구현해야 한다는 것을 의미합니다. 즉, 작업 디렉토리 명령이 실행되는 변경을 의미합니다(생성기/명령이 실행되는 방식에 따라 빌드 구성의 원래 의도가 변경될 수 있음).

그렇다면 subninja 대 include 의 대조 사용 사례는 무엇입니까?

빌드 파일과 관련된 경로가 있는 하위 닌자는 자체 디렉터리 내에서 실행되도록 구성된 종속성이 경로를 수정하지 않고도 수행할 수 있지만 상위 닌자 구성의 종속성 그래프에 계속 기여할 수 있다는 점에서 유용합니다.

include 기능은 수정되지 않고 사실 규칙 이름이 이제 결합된 네임스페이스에 있는 것 외에 서브닌자가 어떻게 작동하는지 정확하게 작동합니다(#921에 따름). 현재 subninja 및 include 는 범위 지정 변수 및 규칙 이름을 제외하고 본질적으로 동일한 결과를 얻습니다...

아이디어는 생성기가 모든 .ninja 파일을 생성하므로 빌드 디렉토리에 상대적인 경로를 작성할 수 있다는 것입니다. 서로 다른 생성기에서 생성된 닌자 파일을 결합하는 것은 흥미로운 아이디어이지만(이것이 당신이 원하는 것 같습니까?), 현재 지원되는 것은 아닙니다.

맞습니다. subninja 와 include 의 차이점은 전자는 범위를 추가하고 후자는 추가하지 않는다는 것입니다. 이에 대한 사용 사례는 최상위 닌자가 cflags 와 같은 변수를 참조하는 cc와 같은 일반적인 빌드 규칙을 정의할 수 있고 각 하위 닌자가 해당 대상에 적합한 것으로 cflags 를 설정할 수 있다는 것입니다. 일회성 작업이 될 수 있습니다. 예를 보려면 python misc/write_fake_manifests.py /tmp/foo`를 실행하여 이 패턴을 사용하는 .ninja 파일을 /tmp/foo에 쓸 수 있습니다.

그것은 의미가 있지만 (범위 제외) 여전히 많은 이점을 보지 못합니다.

다른 생성기에서 생성된 닌자 파일을 결합하는 것은 흥미로운 아이디어입니다.

정확히. Ninja 자체를 내 생성기의 하위 모듈로 포함시킨 다음 다른 CMake 프로젝트(Ninja 빌드 파일을 출력하도록 구성됨)를 포함하고 둘 다에 대해 Ninja 구성 파일을 생성하고 subninja 로 포함할 수 있습니다. _my_ 프로젝트의 build.ninja 파일을 사용하여 마치 자체적으로 빌드하는 것처럼 만들 수 있지만 전체 프로젝트를 한 번에 빌드하기 위해 내 프로젝트에서 출력(및 종속성 그래프)을 사용할 수 있습니다. .

그게 말이 된다면. 특히 내 생성기를 사용하여 볼 수 있는 즉각적인 사용 사례는 Tup(IIRC가 Ninja 자체 내에서 일부 디자인 결정에 영향을 줌)에서 몇 가지 개념을 차용한다는 것입니다 build.ninja 파일을 가져온 다음 그래프를 탭하여 훨씬 더 큰 종속성 그래프를 자동으로 구성할 수 있습니다.

개인적으로 subninja 를 훨씬 더 유용하게 만들 수 있다고 생각하지만 잠재적으로 획기적인 변경이라고 볼 수 있습니다. 그러나 1) 패치로 종속성의 build.ninja 파일을 수정하거나 2) 종속성의 종속성 그래프를 활용하는 기능을 희생하지 않는 한 이 문제를 해결할 방법이 없습니다.

생각?

어때요:

subninja path/to/build.ninja relative path/to

relative 가 없으면 기본값은 ./ 입니다. 그렇게 하면 손상되지 않지만 생성자가 원하는 경우 기능을 계속 제공합니다.

또는 다른 Ninja 구성의 단계를 따르면

subninja path/to/build.ninja
  relative = path/to

.../foo에 프로젝트가 있고 하위 디렉토리 표시줄이 있고 Ninja에 사용자가 제안한 상대 경로 논리가 있다고 가정합니다.

빌드 시스템이 /foo/obj에 모든 빌드 출력을 기록하려는 경우 디렉토리 상대 경로를 사용하는 /foo/bar의 하위 닌자는 출력을 ../obj/bar에 쓰는 방법을 알아야 합니다. 해당 하위 디렉토리의 파일입니다. 따라서 build.ninja 파일을 생성하는 것은 무엇이든 이미 전역 경로 계층 구조를 알고 있어야 합니다. 이 경우 모든 경로를 상대적으로 만드는 것은 bar/ 디렉토리의 경로 앞에 bar/를 추가하는 것과 사실상 동일한 문제입니다.

하지만 위의 내용은 중요하지 않은 소스 디렉토리에 빌드 출력을 작성하는 사람이 충분히 있을 수 있습니다. 나는 주로 Ninja에게 패치를 보내 완전히 관련 없는 디렉토리에서 빌드 출력으로 Ninja를 빌드할 수 있도록 하는 것과 같이 더 강력한 분리를 원하는 사람들의 이야기를 듣습니다.

이해가 잘 안되네요. 내가 특히 설명한 사용 사례에서 Subninjas는 일반적으로 부모 ninja의 구조에 대해 알지 못합니다(적어도 알 필요는 없음). 그래도 누군가가 케이스를 찾을 수 있을 거라고 확신합니다.

내가 지금 직면하고 있는 문제는 내 생성기를 사용하지 않는 종속성(타사 라이브러리 등)(그 중 100%)이 현재 부트스트래퍼를 사용하여 빌드해야 하고 매번 부트스트랩되어야 한다는 것입니다. 내가 작업하는 대부분의 생성기에는 닌자 구성으로 출력하는 옵션이 있지만 모두 해당 디렉터리(즉, 해당 디렉터리에 상대적)에 대해 구성되어 있습니다.

구성과 그래프를 사용하여 선택적 재구축을 수행할 수 있다는 것은 엄청난 일이 될 것입니다. 현재 subninja 가 빌드 디렉토리에 상대적인 경로를 가정하기 때문에 이 작업을 수행할 수 없습니다.

Evan: 내가 이해한 방법은 다음과 같은 트리를 생성한다는 것입니다.

  subbuild1
  subbuild2

그리고 생성기는 일반적으로 빌드 디렉토리를 임의의 위치에 배치하는 것을 지원하므로 subbuild1에서 프로젝트 1을 빌드하고 subbuild 2에서 프로젝트 2가 작동해야 합니다. 그런 다음 Qix가 하위 프로젝트 빌드를 구동하려는 builddir에 최상위 ninja 파일이 있습니다.

관련 없음: 이 relative 기능은 빌드 디렉토리와 동일한 현재 디렉토리에 종속된 규칙이 있는 경우(예: 빌드된 아티팩트 또는 기타 항목을 제거하는 경우) cwd를 인수로 변경해야 합니다.