Ninja: 환경을 통한 자세한 설정 지원

이와 같은 경우 환경 변수를 따르도록 셸 스크립트를 만들 수 있다고 생각합니다. 그렇지 않으면 누군가 VERBOSE=1이 Ninja 이외의 프로그램의 자세한 정도를 제어하기를 원하는 동등한 환경을 생각할 수 있습니다.

이와 같은 경우 환경 변수를 따르도록 셸 스크립트를 만들 수 있다고 생각합니다.

이 환경 변수는 닌자를 위한 것인데, 닌자가 인식하지 못한다면 어떻게 따라갈까요?

또한 스크립트에서 도구의 명령줄을 수정하는 것이 너무 많을 수 있으므로 항상 실행 가능하거나 합리적인 것은 아닙니다. 당신이 제안하는 것은 각 스크립트가 명령에 전달된 플래그를 조정하는 고유한 방법을 채택한다는 것입니다. 이는 또한 비합리적입니다.

이 상황과 관련된 다른 PR 및 문제를 읽었지만 제대로 생각한 답변을 찾지 못했습니다. 각각의 경우 사용자가 ninja 가 실행되는 위치와 방법을 직접 제어하거나 실제로 이에 대해 무엇이든 할 수 있는 위치에 있다고 가정합니다. 특히 구성 시스템에서 ninja.build 스크립트를 생성할 때 그렇습니다. 파이프라인의 일부로.

이 환경 변수는 닌자를 위한 것인데, 닌자가 인식하지 못한다면 어떻게 따라갈까요?

스크립트는 이를 인식하고 -v 를 닌자에게 전달합니다.

따라서 내가 예측한 대로 모든 스크립트 또는 스크립트와 유사한 것이 자체 논리 집합을 인코딩하여 옵션을 닌자에게 전달하기를 기대합니다. 전혀 합리적이지 않습니다.

아니요, 그렇게 하려면 하나의 스크립트만 필요합니다. ninja 라는 이름을 지정하고 실제 닌자 실행 파일 앞에 PATH 넣습니다.

나는 이것이 이미 다른 수많은 문제 보고서에서 다루어졌다고 생각했습니까? 또한 환경을 추적할 수 있는 재현성 빌드 파이프라인에 영향을 미치기 시작하므로 이는 합리적이지 않습니다. 또한 사람들이 귀하가 제안한 것을 수행할 수 있는 능력이 있다고 가정합니다(secure PATH ).

또한 환경을 추적할 수 있는 재현성 빌드 파이프라인에 영향을 미치기 시작하므로 이는 합리적이지 않습니다.

스크립트가 항상 거기에 있으면 닌자 자체가 처리하는 것처럼 VERBOSE 추적할 수 있습니다.

안전하다고 생각 PATH

그게 무슨 뜻 이니?

나는 VERBOSE 관심이 없습니다. NINJAFLAGS 를 통해 플래그를 노출하는 다른 제안이 이 주제에 대한 다른 많은 문제에서 제안된 것처럼 더 적절하다고 생각합니다.

다시 말하지만, 이것은 수백 개의 패키지를 관리할 때 불합리한 요청이며, 그 중 일부는 cmake를 사용하여 ninja 빌드 스크립트를 생성합니다. make (올바르게 생성되거나 작성된 Makefile )와 같은 기존 시스템이 CFLAGS 와 같은 사실상의 환경을 계속 존중할 때 종속성 역할을 하기 위해 불필요한 래퍼를 만드는 것은 과도하게 관련됩니다 Makefile CFLAGS , CXXFLAGS , LDFLAGS 등 뿐만 아니라 MAKEFLAGS -j$(nproc) 효과로 무언가를 설정하는

이것은 다시 안전한 경로의 개념에 이르게 됩니다. sudo 및 build/CI 스크립트와 같은 시스템은 PATH 를 알려진 양호한 기본값으로 설정하여 일반적으로 깨끗한 chroot에 의해 뒷받침되는 빌드의 잠재적 오염을 방지합니다.

그 중 일부는 cmake를 사용하여 닌자 빌드 스크립트를 생성합니다.

이게 어떻게 바뀌는지 모르겠어?

이것은 다시 안전한 경로의 개념에 이르게 됩니다. sudo 및 build/CI 스크립트와 같은 시스템은 일반적으로 깨끗한 chroot에 의해 뒷받침되는 빌드의 잠재적 오염을 피하기 위해 PATH를 알려진 양호한 기본값으로 설정합니다.

이 경우 ninja 바이너리의 이름을 바꾸고 스크립트를 제자리에 배치하여 PATH 수정을 피할 수 있습니다.

그리고 우리는 주위에 간다

이 경우 ninja 바이너리의 이름을 바꾸고 스크립트를 제자리에 배치하여 PATH 수정을 피할 수 있습니다.

이것은 제안하는 것은 매우 부적절합니다.

사용자 는 시스템 수준 바이너리로 장난을 쳐서는 안 됩니다.

시스템 수준 바이너리의 이름을 바꾸고 스크립트로 대체하는 다중 사용자 시스템에는 적합하지 않습니다.

기록을 위해 다시 한 번 말하겠습니다. 저는 C++ 개발 팀을 위한 맞춤형 빌드 시스템을 유지 관리하고 있습니다. 이 시스템은 수백만 줄의 C++ 코드를 컴파일합니다. 예전에는 많은 일을 직접적으로 수행했지만 지금은 닌자 파일을 생성하고 모든 것이 만족스럽습니다. 그래서 저는 이것에 대해 이야기할 때 함께 문질러야 할 몇 가지 단서를 가지고 있습니다.

원하는 것: 자세한 정보 표시 등을 포함하여 다양한 기본값을 설정하는 단일 환경 변수를 닌자 바이너리가 인식하도록 합니다.

내가 받아들일 수 있는 것: Ninja는 여러 환경 변수에 응답합니다.

허용되지 않는 것: 래퍼 스크립트를 작성해야 합니다.

그것이 허용되지 않는 이유: Windows에 배포할 때 잘 작동할 것이라고 생각합니다. 그러나 우리는 기능을 제공하기 위해 시스템의 ninja 패키지에 의존하기 때문에 Linux에서는 허용되지 않습니다. 따라서 Linux 시스템에 배포할 때 "오, 시스템 수준 ninja 패키지의 이름을 바꾸고 스크립트로 교체하십시오"라는 제안은 보안 문제와 유지 관리 문제를 비명을 지르게 합니다. 무엇보다도 지금은 시스템의 패키지 관리자가 닌자 패키지를 업데이트할 때마다 시스템을 가만히 지켜봐야 합니다.

이것은 프로그램에 추가하기에 위험한 기능이 아닙니다. 닌자의 임무는 사용자를 자신으로부터 보호하는 것이 아닙니다. 사용자가 어떻게 든 그것을 망칠 수 있다면 그것은 그들에게 달려 있습니다.

Ninja에 이와 같은 기능을 추가하면 Ninja가 몇 마이크로초 이상 느려질 확률은 존재하지 않을 정도로 낮습니다. 그러나 귀하의 제안은 닌자가 매번 스크립트 인터프리터를 실행하는 것을 포함하는 래퍼 스크립트를 사용한다는 것입니다. 더 많은 오버 헤드가 이미 실행 바이너리에 몇 가지 문자열 비교보다 훨씬 멀리, 이는 시작됩니다.

따라서 Linux 시스템에 배포할 때 "오, 시스템 수준 ninja 패키지의 이름을 바꾸고 스크립트로 교체하십시오"라는 제안은 보안 문제와 유지 관리 문제를 비명을 지르게 합니다.

아니요, Linux에 배포할 때 스크립트를 /usr/local/bin 에 넣는 것이 좋습니다.

내 리눅스 머신에는 그 디렉토리가 없는 것 같다.

파일 시스템 계층 표준 http://www.pathname.com/fhs/pub/fhs-2.3.pdf 에서 참조를 찾을 수 없습니다

FHS에서 /usr/local/sbin에 대한 참조를 찾았습니다. 아마도 그것이 당신이 의미하는 바입니까? 이것을 위해 "sbin" 폴더를 사용하는 것이 이상해 보입니다.

아마도 /usr/local/bin은 /usr/bin 및 기타 이전의 PATH에 있어야 합니다.

그러나 그것은 당신이 말한 것이 아닙니다. 당신은 이렇게 말했습니다.

이 경우 ninja 바이너리의 이름을 바꾸고 스크립트를 제자리에 배치하여 PATH 수정을 피할 수 있습니다.

보안 및 지속적인 유지 관리 문제로 가득 찬 나쁜 제안입니다.

다른 모든 것보다 항상 먼저 포함되는 시스템 전체 디렉토리에 스크립트를 넣는 것이 바이너리 이름을 바꾸고 그 자리에 스크립트를 배치하는 것보다 더 나은 방법입니다.

그럼에도 불구하고, 왜 우리가 닌자 자체에 이것을 포함하지 않고, 자체 일관성이 있고, 스크립트 호출로 인한 많은 오버헤드를 추가하지 않았는지 및/또는 "모든 사람이 자신의 지금 자신의 스크립트"를 작성하고 여기 github에 문서화된 닌자 프로젝트에 대한 지침을 가리켰습니다.

독립적인 Ninja 빌드 언어 재구현 https://github.com/michaelforney/samurai 는 환경 변수 SAMUFLAGS를 통해 이를 지원합니다. 닌자를 사용하려는 모든 곳에서 samu를 사용하거나 시스템 /usr/bin/ninja로 samu를 설치하기만 하면 됩니다(일부 Linux 배포판에는 이 경쟁 구현을 기본 또는 닌자 전용으로 설치하는 옵션이 있습니다).