참조: @nico @chaoren

CMake의 문제 16675 , 문제 13894 및 MR 520 에 관련 토론이 있습니다.

이 문제를 해결하려면 "."도 포함하여 개체 출력 디렉터리를 명시적으로 설정할 수 있습니다. 또는 ".."이지만 절대 경로도 작동합니다.
ninjatst.bash.txt

@zlolik IIUC 빌드 매니페스트( build.ninja ) 그래프 노드에 절대 경로를 배치하는 것이 좋습니다. 확실히 그것은 작동하지만(CMake가 소스 외부 빌드에서 수행하는 작업입니다) 여기서 제 요점은 Ninja는 절대 경로 사용을 권장하지 않지만 IDE는 출력에서 ​​이를 요구한다는 것입니다.

-c foo.c 가 주어진 컴파일러가 어쨌든 depfile에서 절대 경로를 생성할 수 있다는 가설도 가능합니다. 그런 일이 발생하면 Ninja는 여기에 보고된 동일한 문제로 인해 종속성을 인식하지 못합니다.

이 문제를 해결하려면 Ninja가 상대 경로와 절대 경로가 동일한 파일이고 내부적으로 두 개 대신 하나의 그래프 노드만 있는 경우를 인식할 수 있어야 합니다. 빌드 매니페스트 내에서 경로 이름을 일관되게 지정하도록 build.ninja 생성기에 요청하는 것이 합리적이므로 depfile 처리에만 이 작업을 수행하면 충분할 수 있습니다.

@bradking 우선, 닌자에 문제가 있다는 데 동의하며 해결 방법만 제안합니다.
3개의 연결된 문제가 있다고 생각합니다.

1. 입력 절대/상대 경로가 있는 논리, 자세한 내용은 #1152 .
2. 절대/상대 경로를 강제로 출력하는 논리입니다. 컴파일러의 문제 - 출력에 절대 경로를 갖고 싶다고 컴파일러에 알리는 유일한 방법은 명령줄에서 절대 경로를 사용하는 것입니다. 닌자 문제가 아니라 우리 문제입니다.
3. depfile 절대/상대 경로를 구문 분석하는 논리입니다. 이 문제.

2가지 해결 방법을 사용합니다.

1. build.ninja $p 및 $o 접두사를 사용하여 처음 2개의 문제를 해결하십시오. 제 경우에는 $p 및 $o 가 절대적이지 않고 build.ninja 생성기가 실행된 현재 디렉토리에서 상대적입니다.
2. 일부 스크립트를 사용하여 depfile을 닌자 호환 경로로 변환하십시오. 일부 컴파일러는 depfile을 생성하기 위해 별도의 호출이 필요합니다. 그러나 절대 경로 문제는 없습니다.

참고로 저는 제안된 솔루션으로 ninja-build 메일링 리스트에서 스레드 를 시작했습니다.

디버그 및 적용 범위 정보에 대한 또 다른 관련 문제: 상대 경로와 함께 명령을 사용하면 상대 경로가 있는 디버그 정보 파일도 생성됩니다. 문제는 디버그 파일이 일반적으로 소스 파일이 아니라 개체 파일 옆에 위치하므로 해당 위치의 상대 경로가 존재하지 않는 파일을 참조한다는 것입니다.

이에 대한 업데이트가 있습니까? 메일링 리스트 스레드에 응답이 없습니다...

여러분, 안녕하세요,

-c foo.c 주어진 컴파일러가 어쨌든 depfile에서 절대 경로를 생성할 수 있다는 가설도 가능합니다.

IAR v8의 종속성 파일에는 절대 경로만 포함됩니다.

CMake/Ninja/IAR을 사용하여 소스 외부 빌드를 수행할 때 이 문제가 발생했습니다. CMake의 바이너리 디렉토리로 끝나는 생성된 파일은 Ninja 매니페스트에서 상대적이고 IAR의 deps 출력은 절대적입니다.

나에게 이것은 분명히 닌자 문제입니다. 무슨 일이 있어도 동일한 파일에 대해 두 개의 노드가 있어서는 안 됩니다.

@bradking 의 제안 을 읽었지만 심볼릭 링크에 대한 부분과 getcwd() 를 사용할 수 없는 이유를 정말 이해하지 못합니다. 자세히 설명해 주시겠습니까?

나는 심볼릭 링크에 대한 부분과 getcwd() 를 사용할 수 없는 이유를 정말로 이해하지 못합니다.

@sebknzl 문제는 생성기에 의해 build.ninja 에 쓰여진 절대 경로가 이런저런 이유로 의도적으로 해결되지 않은 심볼릭 링크를 포함할 수 있다는 것입니다. getcwd() 는 일반적으로 심볼릭 링크가 확인된 경로를 반환합니다. Ninja가 빌드 매니페스트의 상대 경로 또는 getcwd() 에 상대적인 depfile을 해석하는 경우 Ninja가 구성하는 절대 경로는 빌드 매니페스트 생성기가 사용한 것과 일치하지 않을 수 있으며 여전히 두 개의 노드로 끝납니다.

내가 링크한 스레드에서 제안한 ninja_workdir 는 기본적으로 Ninja에게 상대 경로의 기반으로 사용된 생성기를 알려주는 것입니다. 실제로 realpath(ninja_workdir) == realpath(getcwd()) 는 항상 참이어야 하지만 이것이 ninja_workdir == getcwd() 를 의미하지는 않습니다. 또 다른 대안은 Ninja가 노드를 생성하기 전에 모든 것을 realpath 하는 것이지만 이는 $in 가 생성자가 의도한 대로 확장되지 않는다는 것을 의미합니다.

@jhasse 이 문제와 이를 해결하기 위한 내 제안 을 참조하십시오.

CMAKE_NINJA_GENERATOR_OPTION_ 에 의해 제어되는 절대 경로로 _build.ninja_ 를 생성하지 않는 이유는 무엇입니까?

즉, 다음과 같이 작동합니다.

Claus-MBP:build clausklein$ cat build.ninja 

# project dir
p = /Users/clausklein/Downloads
# object dir
o = /Users/clausklein/Downloads/.ninjatst.build

rule cp
  command = cp $in $out

rule cc
  depfile = $out.d
  deps = gcc
  command = cc -I$o -c $in -o $out -MD -MT $out -MF $out.d

# All absolute paths works
build all: phony $o/foo.o

# All absolute paths works
build $o/foo.h: cp $p/foo.h.in
  IN = $p/foo.h.in

# All absolute paths works
build $o/foo.o: cc $p/foo.c || $o/foo.h
  IN = "$p/foo.c"

default all

Claus-MBP:build clausklein$ 

ninjatst.bash.txt 로 생성

@ClausKlein 우리는 CMake에게 절대 경로를 사용하도록 가르치려고 했습니다. https://github.com/ninja-build/ninja/issues/1251#issuecomment -282322776에 링크된 토론을 참조하세요. "일부 경우를 수정하고 다른 경우를 중단시키는 다른 방식으로 작업을 수행하십시오"라는 옵션을 추가하지 않는 것이 좋습니다.

이 문제를 올바르게 수정 하려면 https://github.com/ninja-build/ninja/issues/1251#issuecomment -487618865에 링크된 제안서에 Ninja 기능이 정말 필요합니다.

알았어 괜찮아

그런 다음 mesonbuild 시스템에 대한 이 수정 사항도 사용할 수 있습니까 ;-)

Am 12.03.2020 um 12:56 schrieb Brad King [email protected] :

@ClausKlein https://github.com/ClausKlein 우리는 CMake에게 절대 경로를 사용하도록 가르치려고 했습니다. #1251 (comment) https://github.com/ninja-build/ninja/issues/1251#issuecomment-282322776 에서 링크한 토론을 참조하세요. "일부 경우를 수정하고 다른 경우를 중단시키는 다른 방식으로 작업을 수행하십시오"라는 옵션을 추가하지 않는 것이 좋습니다.

이 문제를 올바르게 수정하려면 #1251(comment) https://github.com/ninja-build/ninja/issues/1251#issuecomment-487618865 에 링크된 제안서의 Ninja 기능이 정말 필요합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub https://github.com/ninja-build/ninja/issues/1251#issuecomment-598146822 에서 확인하거나 https://github.com/notifications/unsubscribe-auth/AAN7QWWEDHMDA45DQVPLOUDRHDEVDANCNFSM4DBNL6GA 구독을 취소하세요.

Ninja가 일치하는 depfile 정보에 ninja_workdir 를 사용하고 심볼릭 링크로 인해 ninja_workdir != getcwd() 인 상황이 있다고 가정해 보겠습니다. 컴파일러가 이제 getcwd() 를 사용하여 절대 경로를 인쇄하면 어떻게 됩니까?

컴파일러는 상대 경로로 전달되지 않는 한 getcwd() 를 사용해서는 안 됩니다. 이 경우 빌드 시스템 생성기가 책임을 져야 합니다.

또는 ninja_workdir 및 getcwd() 모두를 정규화하는 것을 고려할 수 있습니다.

글쎄, 컴파일러는 상대 경로가 주어질 때 depfile에서 절대 경로를 반환 해서는 안됩니다 .

@ClausKlein 우리는 CMake에게 절대 경로를 사용하도록 가르치려고 했습니다. #1251(댓글)에 링크된 토론을 참조하세요. "일부 경우를 수정하고 다른 경우를 중단시키는 다른 방식으로 작업을 수행하십시오"라는 옵션을 추가하지 않는 것이 좋습니다.

@ClausKlein이 제안한 대로 절대 경로를 사용했을 때 정확히 어떤 문제가 발생했습니까?

컴파일러에 절대 경로가 주어지면 생성하는 depfile은 절대 경로를 가지며, 이는 생성된 헤더의 경우와 같이 빌드 매니페스트의 헤더에 대한 상대 경로와 조정되지 않습니다. 이 문제의 맨 위에 있는 내 첫 번째 게시물의 ninja-bug.bash.txt 링크를 참조하세요. 그것은 일어나는 일에 대한 단계별 예를 보여주며 CMake가 아닌 Ninja의 관점에서 순수하게 표현됩니다.

나는 그것을 읽었지만 왜 https://github.com/ninja-build/ninja/issues/1251#issuecomment -284533599를 사용하지 않습니까? 단순히 닌자가 절대 경로를 "절대"하기 때문에? 그렇다면 이것은 문서 변경에 관한 것입니까?

build.ninja 파일은 모든 곳에서 절대 경로를 반복하지 않고 훨씬 작아서 더 빨라집니다. 또한 더 보기 좋고 디버그하기 쉽고 셸에서 빌드 대상 이름의 탭 완성에 더 적합합니다. IMO는 Ninja가 만드는 좋은 권장 사항입니다. Ninja는 이 경우를 조정하기 위해 조금 더 많은 정보가 필요하며 이것이 제가 제안하는 것입니다.

@bradking 상대 경로가 항상 짧은 것은 아닙니다.

build jsoncpp@sha/src_lib_json_json_reader.cpp.o: cpp_COMPILER ../../../../../Users/clausklein/Workspace/cpp/jsoncpp/src/lib_json/json_reader.cpp
 DEPFILE = jsoncpp@sha/src_lib_json_json_reader.cpp.o.d
 ARGS = -Ijsoncpp<strong i="7">@sha</strong> -I. -I../../../../../Users/clausklein/Workspace/cpp/jsoncpp -I../../../../../Users/clausklein/Workspace/cpp/jsoncpp/include -I../../../../../Users/clausklein/Workspace/cpp/jsoncpp/dir1 -I../../../../../Users/clausklein/Workspace/cpp/jsoncpp/dir2 -fdiagnostics-color=always -pipe -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++17 -O3

내 예는 https://github.com/ninja-build/ninja/issues/1251#issuecomment -597877775가 더 좋아 보입니다!

CMake의 생성기에는 빌드 트리를 떠나는 ../ 시퀀스를 사용하지 않는 것에 대한 규칙이 있습니다. 완전히 소스 외부 빌드에서 소스 트리에 대한 절대 경로와 빌드 트리 내 상대 경로를 사용합니다. 후자는 빌드 트리 아래에 있으므로 ../ 에서 시작하지 않습니다.

알고 보니 _mesonbuild_ 로 생성되었습니다. ;-)

하지만 그보다 소스 트리로의 생성을 거부하는 것은 어떻습니까?

우리는 상대 경로와 절대 경로의 장점에 대해 영원히 논쟁할 수 있습니다. 닌자는 그것에 대해 독단적이어서는 안 됩니다. 여기서 문제는 단일 빌드 내에서 둘 다 사용되는 경우를 조정하는 것입니다. 빌드 시스템 생성기는 도구가 경로로 수행할 작업을 항상 제어할 수는 없습니다. Ninja는 동일한 파일에 대한 혼합 절대/상대 경로를 지원해야 하며 내 제안서에 설명된 간단한 접근 방식으로 그렇게 할 수 있습니다. 동기 부여 사용 사례의 경우 변경 사항은 depfile 구문 분석으로 격리됩니다.

Ninja는 동일한 파일에 대한 혼합 절대/상대 경로를 지원해야 합니다.

나는 동의한다!

모든 설명에 감사드립니다. 이해하기 시작했습니다.

Ninja가 (depfile에서 절대 경로를 만나면) cwd와 찾은 경로를 모두 실제 경로로 지정하면 어떻게 될까요? 그런 다음 실제 경로가 지정된 depfile-path에서 실제 경로가 지정된 cwd를 제거하여 생성된 헤더와 일치하는 상대 경로를 가져옵니다. 그게 효과가 있을까요?

getcwd() 는 항상 이미 실제 경로이므로 해당 단계가 필요하지 않습니다. Ninja가 realpath() 인 경우 depfile이 제공한 절대 경로와 작동할 수 있는 cwd 접두사를 확인합니다. 그러나 realpath() 는 아마도 값비싼 시스템 호출인 반면 제안된 ninja_workdir 은 문자열 처리를 통해 메모리에서 경로를 순전히 조정할 수 있습니다.

다른 방향의 혼합도 허용되어야 합니다. 빌드 매니페스트의 절대 경로이지만 depfile의 상대 경로입니다. 나는 Ninja가 build.ninja 구문 분석하는 동안 모든 절대 경로를 realpath() 해야 한다고 생각하지 않습니다. 아마 느릴 것입니다.

결과를 사용하여 작업 디렉토리를 결정할 수 있습니다. 예:

getcwd(): /var/xyz/build
depfile 항목: /home/foo/build/bar.h
실제 경로(depfile 항목): /var/xyz/build/bar.h
상대 실제 경로: bar.h
depfile 항목에서 제거: /home/foo/build -> ninja_workdir

이런 식으로 우리는 realpath를 한 번만 호출하면 됩니다.

일반적으로 ninja_workdir 를 자동으로 유도하는 것은 불가능하다고 생각합니다. 원래 symlink를 포함하는 논리적 경로의 논리적 구성 요소가 workdir에 해당하는지 어떻게 알 수 있습니까? 실제 경로가 cwd와 일치할 때까지 한 번에 하나의 구성 요소를 사용하여 이를 수행할 수 있지만 해킹 및 오류가 발생하기 쉽습니다. 이렇게 생긴 첫 번째 심볼릭 링크를 신뢰하는 것은 위험합니다. 또한 우리는 이런 식으로 해결될 때까지 만나는 모든 절대 경로에 대해 realpath()를 실행해야 합니다.

빌드 시스템 생성기는 build.ninja 의 빌드 문 및 명령줄에서 절대 경로를 생성할 때 사용했던 workdir에 대한 논리적 경로를 정확히 알고 있습니다. 따라서 이것은 workdir 경로에 대한 가장 신뢰할 수 있는 정보 소스입니다. 우리는 이 정보를 Ninja에게 전달할 방법이 필요하므로 제안한 ninja_workdir 바인딩입니다.

제가 이해했는지 잘 모르겠습니다. 죄송합니다. 내 감지 논리가 작동하지 않는 예를 들어 주시겠습니까?

빌드 시스템 생성기가 빌드 트리 내부에 심볼릭 링크를 넣으면 중단될 수 있습니다(빌드 트리의 다른 곳이나 외부를 가리킴).

getcwd(): /var/xyz/build
depfile 항목: /home/foo/build/subdir-link/bar.h
실제 경로(depfile 항목): /var/xyz/build/subdir-real/bar.h
상대 실제 경로: subdir-real/bar.h
depfile 항목에서 제거: ???

CMake는 이것을 하지 않지만 일반적으로 빌드 시스템 생성기는 할 수 있습니다.

지원되지 않는다고 말할 수 있더라도 탐지는 여전히 다음과 같은 상황에 직면할 수 있습니다.

getcwd(): /var/xyz/build
1000개의 depfile 항목: /home/foo/ext-lib/bar{1,2,...}.h
1000개의 실제 경로(depfile 항목): /var/xyz/ext-lib/bar{1,2,...}.h
1000 상대 실제 경로: cwd 아래에 없음

이제 그것이 1000개의 소스의 depfile에 나타나고 히트가 없다고 상상해보십시오. 이는 이 휴리스틱에 대한 일치 항목이 없는 100만 개의 realpath() 호출입니다. 소스가 다시 빌드되고 해당 depfile이 다시 구문 분석될 때마다 반복됩니다.

빌드 트리 내부의 symlink -> 예, 실제로 지원할 수 없습니다. 어쨌든 모든 종류의 다른 문제가 발생할 것입니다(모든 곳에서 실제 경로 지정 없이).

두 번째 예는 다소 인위적으로 들립니다. 일반적으로 depfile은 시스템 헤더가 아닌 로컬 종속성으로 시작합니다.

실제로 성능 문제로 판명되면 .ninja_deps 에 workdir을 캐시할 수 있습니까?

소스 외부 빌드에서는 빌드 트리를 가리키는 depfile 항목이 거의 없습니다. 이것은 매우 일반적일 것입니다:

getcwd(): /var/xyz/build
1000개의 depfile 항목: /home/foo/project-source/bar{1,2,...}.h
1000개의 실제 경로(depfile 항목): /var/xyz/project-source/bar{1,2,...}.h
1000 상대 실제 경로: cwd 아래에 없음

Ninja는 만일의 경우를 대비하여 이들 모두에 대해 realpath() 를 호출하거나 실제 시스템 호출을 피하기 위해 일종의 결과 테이블을 유지해야 합니다. 그것은 cwd로 해석되는 심볼릭 링크 경로를 만날 때를 미리 알 수 없으며 찾을 것인지 조차 모릅니다.

현재 depfile에서 절대 경로와 실제 경로를 혼합하는 것이 작동하지 않는다는 점을 감안할 때 이것이 어떻게 "매우 일반적"인지 알 수 없습니다.

내 예에서 형식의 depfile은 심볼릭 링크나 혼합 경로를 사용하지 않는 경우에도 이미 매우 일반적입니다. 대부분의 빌드 트리에 있습니다. Ninja는 휴리스틱이 필요한지 여부를 미리 알 수 없으므로 만일을 대비하여 realpath() 시스템 호출을 차단해야 합니다.

내가 당신의 예를 잘못 이해했을 수도 있습니다. 3000개 항목이 있는 하나의 depfile을 의미합니까 아니면 각각 1000개 항목이 있는 depfile에 대한 3개의 개별 예를 의미합니까?

나는 1000개의 depfile 항목이 여러 depfile에 걸쳐 있다는 것을 의미했습니다. 하나가 될 수 있습니다. 많을 수 있습니다. 프로젝트 전체에 10000개의 항목이 있을 수 있습니다. 그들의 경로는 파일 시스템의 아무 곳이나 가리킬 수 있으며 실제로 빌드 트리를 가리킬 수도 있고 그렇지 않을 수도 있습니다.

경로가 혼합된 결과를 초래하는 CMakeLists.txt 의 예를 제공할 수 있습니까(1000일 필요는 없고 각각 하나씩만)?

CMake는 현재 대부분의 경우 경로가 혼합되지 않도록 주의하기 때문에 CMakeLists.txt 파일에 표시하기 어렵습니다. 그러나 CMake의 문제 추적기에는 Ninja가 먼저 해결하지 않고는 해결할 수 없는 문제에 대한 문제가 있습니다. 예를 들어 CMake 문제 13894 를 참조하십시오. 사용자는 빌드 트리의 소스(및 아마도 디렉토리 포함)에 대해 또는 소스 내 빌드를 수행할 때에도 컴파일러에 절대 경로를 제공할 수 있기를 원합니다. 이것은 CMake의 Makefile 생성기와 잘 작동합니다. Ninja로 그렇게 하면 depfiles는 절대 경로로 돌아오고 build.ninja 의 상대 경로와 일치하지 않습니다. 아마도 우리는 모든 것에 대해 절대 경로로 전환할 수 있지만, 여기서 위에서 논의한 것처럼 우리는 그렇게 할 필요가 없습니다.

아마도 테스트를 위해 이것을 시도 할 수 있습니다 https://github.com/ClausKlein/build-performance/commit/8013836486e3a459474eb374f6c3da5e20983443

여기에 표시된 문제는 https://github.com/ninja-build/ninja/issues/1251#issue -210080507을 기반으로 합니다.
원하는 만큼의 타겟을 생성합니다. 즉, 각각 2개의 소스 파일이 있는 2명의 정복자:

PWD=/Users/clausklein/Workspace/build-performance/build

rule cp
  command = cp $in $out

rule cc
  depfile = $out.d
  deps = gcc
  command = gcc -c -I$PWD $IN -o $out $FLAGS -MMD -MT $out -MF $out.d

rule link
  command = gcc -o $out $in $LINK_PATH $LINK_LIBRARIES

build foo: phony foo.h
build foo.h: cp foo.h.in

build bin/main0.o: cc /Users/clausklein/Workspace/build-performance/build/subdir0/main.c || foo.h
  IN = /Users/clausklein/Workspace/build-performance/build/subdir0/main.c
build /Users/clausklein/Workspace/build-performance/build/subdir0/file0.o: cc /Users/clausklein/Workspace/build-performance/build/subdir0/file0.c || foo.h
  IN = /Users/clausklein/Workspace/build-performance/build/subdir0/file0.c

build bin/main1.o: cc /Users/clausklein/Workspace/build-performance/build/subdir1/main.c || foo.h
  IN = /Users/clausklein/Workspace/build-performance/build/subdir1/main.c
build /Users/clausklein/Workspace/build-performance/build/subdir1/file0.o: cc /Users/clausklein/Workspace/build-performance/build/subdir1/file0.c || foo.h
  IN = /Users/clausklein/Workspace/build-performance/build/subdir1/file0.c

build bin/main0: link bin/main0.o /Users/clausklein/Workspace/build-performance/build/subdir0/file0.o 
build bin/main1: link bin/main1.o /Users/clausklein/Workspace/build-performance/build/subdir1/file0.o 

build all: phony foo bin/main0 bin/main1 
default all

이것은 CMake의 Makefile 생성기와 잘 작동합니다.

Make는 심볼릭 링크 문제를 어떻게 처리합니까?

Make는 심볼릭 링크 문제를 어떻게 처리합니까?

Makefile 생성기는 현재 depfiles를 사용하지 않으며 자체적으로 대략적인 스캔을 수행합니다. 이는 Makefile 생성기에 C++20 모듈 지원을 추가하는 일부로 업데이트될 것입니다. 이 시점에서 depfile 경로의 해석은 여기에 제안된 것과 유사하게 조정되어야 합니다.

한 가지 옵션은 지금은 ninja_workdir 을 건너뛰고 $ getcwd() 가 맨 위에 있다고 가정하고 혼합 경로를 조정하도록 Ninja에게 최소한 가르치는 것입니다. 그런 식으로 최소한 혼합 경로는 심볼릭 링크가 없는 일반적인 경우에 작동합니다. 그런 다음 나중에 더 복잡한 경우를 지원하기 위해 ninja_workdir 를 추가할 수 있습니다.

누군가 이 문제를 해결해 주세요. 이것 때문에 너무 짜증이 난다.

CMake 및 VSCode와 함께 ARM-GCC를 사용하고 있습니다. 소스 내 빌드를 사용할 때 경로는 루트 디렉터리 대신 "빌드" 디렉터리에 상대적이므로 VSCode가 더 이상 경로를 확인할 수 없습니다. 즉, 명령줄 창에서 경로를 찾는 대신 각 파일을 직접 찾아야 합니다. CMake 트리 외부 빌드를 사용하면 Eclipse의 "IntelliSense"가 중단되고 CMake 하위 프로젝트에 문제가 발생합니다. 현재 내 솔루션은 기본적으로 절대 경로를 사용하기 때문에 MakeFiles를 사용하는 것입니다. 그러나 Ninja가 더 낫고 더 읽기 쉬운 파일(rules.ninja...)을 생성하며 명령줄의 빌드 출력이 더 좋습니다. Make는 다중 스레드 컨텍스트에서 명령줄에 경고를 출력하는 데 문제가 있습니다. 즉, 여러 경고가 인터리브됩니다. 이로 인해 단일 스레드를 구축하게 되며, 이는 다시 매우 성가신 일입니다.

누군가 이 문제를 해결해 주세요. 이것 때문에 너무 짜증이 난다.

CMake 및 VSCode와 함께 ARM-GCC를 사용하고 있습니다. 소스 내 빌드를 사용할 때 경로는 "빌드" 디렉토리에 상대적입니다...

해결 방법이 있습니다. 소스 트리 외부에서 빌드 디렉토리를 선택하십시오! 즉 _$TMPDIR/..._

ClausKlein에게 감사합니다. 하지만 해결 방법은 소스 외 빌드이지만 다른 스크립트에서 참조하기 때문에 트리 내부에 파일이 필요합니다. 또한 비표준 빌드 요구 사항입니다.

지금 내 솔루션은 항상 절대 경로를 사용하도록 CMake를 변경하는 것입니다. 왜 이것에 대한 옵션이 없는지 이해할 수 없습니다. 그러나 다른 사람이 이것을 필요로 하는 경우 CMake v3.18.1 패치가 있습니다.

@@ -241,7 +241,7 @@ void cmNinjaTargetGenerator::AddIncludeFlags(std::string& languageFlags,
   // Add include directory flags.
   std::string includeFlags = this->LocalGenerator->GetIncludeFlags(
     includes, this->GeneratorTarget, language,
-    language == "RC", // full include paths for RC needed by cmcldeps
+    true, // full include paths for RC needed by cmcldeps
     false, config);
   if (this->GetGlobalGenerator()->IsGCCOnWindows()) {
     std::replace(includeFlags.begin(), includeFlags.end(), '\\', '/');
@@ -1133,8 +1133,7 @@ void cmNinjaTargetGenerator::WriteObjectBuildStatement(
   const std::string& fileConfig, bool firstForConfig)
 {
   std::string const language = source->GetLanguage();
-  std::string const sourceFileName =
-    language == "RC" ? source->GetFullPath() : this->GetSourceFilePath(source);
+  std::string const sourceFileName = source->GetFullPath();
   std::string const objectDir = this->ConvertToNinjaPath(
     cmStrCat(this->GeneratorTarget->GetSupportDirectory(),
              this->GetGlobalGenerator()->ConfigDirectory(config)));

주의 , cmake에 대한 패치가 있었지만 https://github.com/ninja-build/ninja/issues/1251 참조

닌자 패치가 필요합니다!

내 마지막 의견에서 상대 경로 대신 절대 경로를 사용하는 CMake용 패치를 보여주었습니다. 이것은 Ninja와의 사용자 지정 CMake 헤더 종속성을 깨기 때문에(예를 들어 생성된 헤더 파일이 .json 파일에 종속되기 때문에) 이것은 나쁜 생각입니다. 이 문제는 여기 이 문제에서 파생된 것 같아요. 제가 너무 어리석어서 이해하지 못했습니다.

누군가 관심이 있다면 이제 상대 경로와 함께 Ninja를 사용합니다. 통합 터미널 내부의 상대 경로를 클릭할 수 있도록 VSCode용 확장을 만들었습니다. 확대

@GrandChris 대단해! Output 탭에서도 작동하게 할 기회가 있습니까?

@weliveindetail 자유롭게 https://github.com/GrandChris/TerminalRelativePath/issues 에서 새 문제를 만들고 사용 사례를 자세히 설명하세요. 그러나 VSCode의 출력 탭은 통합 터미널과 다르게 동작하며 이와 관련하여 동작을 확장하는 API가 없다고 생각합니다.

알았어 고마워. 결국 클릭 가능한 상대 경로는 VSCode 또는 CMake 확장에서 해결해야 합니다. 그들의 편에 핑을 댈 것입니다.

참고로 이것은 CMake Issue 21865 에서 다시 나타났습니다. 이는 depfile에서 발견된 종속성이 build.ninja 와 정확히 동일한 경로 표현을 사용하도록 하는 것이 쉽지 않은(가능한가요?) 경우의 또 다른 예입니다.

1917은 위에서 제안한 ninja_workdir 바인딩을 자체적으로 유용한 기능으로 추가합니다. 병합되면 이 문제에 대한 수정 사항을 후속 조치할 수 있습니다.

@jhasse 이 고정된 업스트림을 얻기 위해 수용 가능한 솔루션을 제시하고 싶습니다. ninja_workdir 이 문제를 해결합니다. 나는 위에서 나의 경우를 주장했다. 다른 어떤 대안을 제안합니까?

당신이 지적했듯이 문제(depfile 절대 경로를 매니페스트 상대 경로와 혼합하면 다시 빌드가 중단됨)는 의도적으로 설계된 것입니다. 논의에서 여러 문제(예: 빌드 디렉토리 심볼릭 링크)를 다루었기 때문에 보다 구체적인 문제를 만들어야 한다고 생각합니다.

초기 주석의 두 가지 사용 사례의 경우 대안은 다음과 같습니다.

이렇게 하면 IDE가 오류 메시지와 일치하고 원본 파일을 다시 참조하도록 더 나은 출력을 생성합니다.

IDE를 수정하거나 /FC 또는 -fabs-path-diagnostics 를 컴파일러에 전달합니다.

디버그 정보에 기록된 경로에도 영향을 미칠 수 있습니다.

이것은 또한 컴파일러에 의해 수정되어야 합니다. -fdebug-prefix-map 를 살펴보는 것이 좋겠지만 문제가 정확히 무엇인지 잘 모르겠습니다.

다음은 문제를 보여주는 스크립트입니다. ninja-bug.bash.txt

실제로는 Ninja의 현재 행동을 보여줍니다. 두 가지 문제

1. "내 IDE가 컴파일러의 출력을 올바른 파일과 일치시킬 수 없습니다"
2. "디버그 정보에 절대 경로가 필요합니다"

추가 설명이 필요합니다. 그렇지 않으면 이것은 나에게 XY 문제 처럼 보입니다(X는 "절대 및 상대 경로 혼합"이고 Y는 1 또는 2임).

솔루션이 "다른 모든 도구에서 이 문제를 해결"해야 한다고 생각하지 않습니다.

1924는 ninja_workdir 접근 방식을 기반으로 테스트를 통해 완벽하게 작동하는 수정 사항을 보여줍니다. 이것을 사용하는 발전기는 위의 모든 문제를 해결할 수 있습니다.

나는 그것들을 해결 방법으로 보지 않기 때문에 나도 마찬가지입니다.

이것은 GNU gcc 옵션이 아닙니다!

오전 05.03.2021 음 16:58 schrieb Jan Niklas Hasse [email protected] :

IDE를 수정하거나 /FC https://docs.microsoft.com/de-de/cpp/build/reference/fc-full-path-of-source-code-file-in-diagnostics 또는 -fabs-를 전달합니다. 경로 진단 https://reviews.llvm.org/D23816 컴파일러에.

디버그 정보에 기록된 경로에도 영향을 미칠 수 있습니다.

다음은 문제를 보여주는 스크립트입니다. ninja-bug.bash.txt

실제로는 Ninja의 현재 행동을 보여줍니다.

인용한 내 게시물은 이것이 현재 문서화된 동작임을 인정합니다.
이 문제의 목적은 다음과 같이 설계 에 문제를 제기하는 것입니다.
제공하지 않는 사용 사례 클래스를 시연합니다.

두 가지 문제 ... (1) ... (2) ... 추가 설명이 필요합니다.

그것들은
도구에 절대 경로를 전달합니다. 절대경로는 무리하지 않다
그러한 특정 사례에서 다른 솔루션을 사용할 수 있기 때문에
문제(일부 공급업체에서 제공하는 특정 도구 기능 사용).
절대 경로는 업데이트 없이 이러한 많은 문제를 해결하는 데 도움이 됩니다.
나머지 생태계에. 내가 이전에 게시한 바와 같이:

우리는 상대 경로와 절대 경로의 장점에 대해 영원히 논쟁할 수 있습니다. 닌자는
그것에 대해 의견을 가지지 마십시오. 여기서 문제는 다음과 같은 경우를 조정하는 것입니다.
둘 다 단일 빌드 내에서 사용됩니다. 빌드 시스템 생성기는 항상
도구가 경로로 수행할 작업을 제어합니다.

복잡한 실제 빌드 시스템에는 임의의 수의 레이어가 있을 수 있습니다.
(모든 종류의 공급업체에서) 스크립트, 래퍼, 도구 등
빌드 파일 생성기에 의해 build.ninja 로 작성된 경로와 실제 경로
depfile에서 Ninja가 만났습니다. 때때로 주어진 파일은 다음에서 참조할 수 있습니다.
build.ninja 에서 경로가 직접 지정되지 않은 도구의 depfile.
Ninja의 현재 디자인에서 depfile이 작동하려면 전체 도구가
스택은 build.ninja 생성기가 어떻게 표현하도록 선택하는지 정확히 알려야 합니다.
빌드 문의 해당 경로 및 기능을 유지하거나 변환
같은 방식으로 그들을. 이것은 일반적으로 다루기 어렵습니다.

Ninja는 작은 디자인 변경으로 이 문제를 해결할 수 있습니다.
build.ninja 의 상대 경로가 있는 depfile의 절대 경로(및 그 반대
반대로). 동일한 파일에 대한 임의의 경로를 조정하도록 요청하는 것이 아니라
depfile의 /path/to/some/file 가 some/file의 some/file 와 동일함을 인식합니다.
빌드 파일 /path/to/build.ninja .

이러한 디자인 업데이트에 대한 선례가 있습니다. 닌자가 처음 시작했을 때 희망은
경로는 항상 정확히 같은 위치에서 ninja 에 의해 발생한다는 것입니다.
빌드 파일 생성기가 작성한 바이트 단위 표현
build.ninja . git blame -M -C -w -- src/util.cc 를 실행하고 기록을 확인하십시오.
CanonicalizePath 중 발생한 일련의 사례를 보려면
디자인 철학은 여유로워야 했습니다. 이것은 그러한 경우의 또 다른 부류입니다.

문제는 내가 동의하지 않는다는 것입니다

닌자는 그것에 대해 독단적이어서는 안 됩니다.

처음에는.

이것은 일반적으로 다루기 어렵습니다.

그렇다면 구체적인 문제는 무엇입니까? 죄송합니다. 약간 혼란스럽습니다.

나는 "닌자가 그것에 대해 독단적이어서는 안된다"는 말에 애초에 동의하지 않는다....그래서 구체적인 문제는 무엇인가?

이것은 특정 문제에 대한 것이 아니라 절대 경로를 사용하여 훨씬 쉽게 해결할 수 있는 전체 문제 클래스 에 대한 것입니다. 개발자가 도구에 절대 경로를 전달하려는 이유 는 중요하지 않으며 특정 경우에 적용되는 이유가 무엇이든 절대 경로를 사용하려는 것뿐입니다. 빌드 시스템은 정책을 지시하는 것이 아니라 사용자에게 서비스를 제공하기 위해 존재합니다. Ninja는 빌드 시스템용 어셈블리 언어로 되어 있지만 혼합 스타일 경로를 사용하여 빌드 시스템을 표현할 방법이 없습니다.

업스트림 변경에 대한 Ninja의 정책 은 효율성 손실 없이 해결할 수 있는 경우 Ninja 업스트림이 아니라 빌드 파일 생성기로 문제를 해결해야 한다는 것입니다. 이 경우 빌드 파일 생성기에서 depfile 경로의 범용 ninja_workdir 스타일 조정을 제공하는 유일한 방법은 depfile을 생성하는 모든 명령 다음에 depfile의 경로를 일치하도록 수정하는 추가 명령을 주입하는 것입니다. 닌자가 로드하기 전에 빌드 파일. 이 추가 명령은 #1924가 수행하는 것보다 훨씬 높은 자체 런타임 비용을 갖습니다( ninja 프로세스 내에서 적은 수의 추가 메모리 내 조회). 따라서 범용 조정은 Ninja 업스트림에서 제공하는 것이 더 효율적이며 포함 후보이기도 합니다.

절대 경로와 상대 경로를 혼합하지 않고 모든 것에 절대 경로를 사용하더라도 성가신 인체 공학 문제가 있습니다. 사용자가 ninja 에 가짜 대상이 아닌 특정 출력 파일을 재생성하도록 요청하는 경우(예: ninja out/my_executable 또는 ninja out/foo/bar.o ) 절대 경로 또는 ninja를 전달해야 함을 기억해야 합니다. 혼란스러운 "알 수 없는 대상" 오류와 함께 실패합니다. 반대 문제도 존재합니다. build.ninja 파일이 상대 경로를 사용할 때 사용자가 닌자에게 절대 경로를 다시 작성하도록 요청할 수 있습니다.

내가 유지 관리하는 한 Ninja 생성기 도구에서 모든 단일 build 문에 상대 경로와 해당 절대 경로를 출력으로 포함하여 이 문제를 해결합니다. 작동하지만 Ninja의 한계를 해결하기 위한 해킹처럼 느껴집니다. (편집: 또한 build.ninja가 상대 경로만 사용하므로 다른 절대 경로로 이동한 후에도 여전히 작동할 수 있는 경우 절대 경로 별칭을 추가하면 해당 기능이 중단됩니다.)

분명히 이것은 depfiles와 정확히 같은 문제는 아니지만 Ninja는 일반적으로 절대 경로와 상대 경로 동등성에 대해 더 잘 알고 있어야 함을 시사합니다.

@comex 감사합니다. 타당한 우려입니다. 당신은 그것에 대한 새로운 문제를 열 ​​수 있습니까?

개발자가 도구에 절대 경로를 전달하려는 이유는 중요하지 않습니다. [...]

나는 동의하지 않는다.

이 경우 범용 ninja_workdir - 스타일의 depfile 경로 조정을 제공하는 유일한 방법은 [...]

그런데 왜 처음에는 ninja_workdir -스타일 화해가 필요합니까?

처음에 ninja_workdir 스타일 조정이 필요한 이유는 무엇입니까?

개발자는 build.ninja 에서 상대 경로를 사용하면서 제어하지 않는 도구를 사용하여 depfile에서 생성된 절대 경로를 계속 처리할 수 있습니다. 그렇지 않으면 닌자의 설계상 제한과 함께 이러한 도구를 수용하기 위해 build.ninja 에서 절대 경로를 사용해야 할 수 있습니다. 내 제안은 상대 경로 사용을 금지하지 않습니다. 더 많이 사용할 수 있습니다.

ninja_workdir 바인딩 없이 #1924와 동일한 조정을 구현하기 위해 #1925를 열었습니다. 이는 depfile 경로를 조정하기로 한 결정과 심볼릭 링크가 있는 논리적 workdir 경로를 지원하기로 한 결정을 구분합니다.

[...] 제어하지 않는 도구에 의해 depfile에서 생성된 절대 경로.

그러한 도구에 대한 예가 있습니까?

우리는 전 세계 모든 사람이 사용하는 모든 도구의 동작을 예측할 수 없습니다. 우리가 제어하는 ​​도구의 경우에도 절대 경로로 쉽게 해결할 수 있지만 상대 경로로 해결하려면 도구별 옵션과 상당한 주의가 필요한 여러 경우에 대해 이미 논의했습니다. CMake는 비슷한 이유로 여러 경우에 절대 경로를 선호합니다. 다른 모든 생성기가 하는 동안 Ninja 생성기가 그렇게 하지 않는다는 몇 가지 버그 보고서가 있습니다. 나는 의존성 문제를 추적하는 데 몇 시간을 소비했는데, 이것이 빌드 매니페스트 경로와 일치하지 않는 depfile 경로의 또 다른 인스턴스라는 것을 알게 되었습니다. 도구는 Ninja가 종속성을 캡처하는 데 필요한 정보를 제공하지만 Ninja는 이를 무시합니다.

귀하의 입장은 상대 경로가 보편적으로 더 낫다는 의견으로 나타납니다. 다른 사람들은 어떤 경우에는 절대 경로가 더 낫다는 다른 의견을 가지고 있습니다. 상대경로를 복음화하기 위한 빌드툴의 자리가 아닌가 싶습니다.

내 제안은 Ninja에 소량의 인프라를 추가합니다. 그것은 무엇을 아프게합니까? 그것을 가지고 있지 않으면 훨씬 더 큰 비용을 외부화합니다.

응 그것은 사실이야!

그리고 절대 경로를 사용하여 cmake는 중복 컴파일러 포함 경로를 제거할 수 있습니다.
이렇게 하면 빌드 시간이 다시 단축됩니다.

오전 09.03.2021 음 19:20 schrieb Brad King [email protected] :

상대경로를 복음화하기 위한 빌드툴의 자리가 아닌가 싶습니다.

Qt의 Quick 컴파일러에서 cpp 파일을 생성하고 Unity 빌드를 활성화하면서 직면한 문제와 관련하여 CMake 문제를 설정했습니다. 내 지역 조사에 따르면 닌자가 훨씬 빠른 빌드 시스템이지만 이 별자리에서는 신뢰할 수 없습니다. 이제 해결 방법을 찾거나 빌드 시간 증가를 정당화할 수 있는 방법에 문제가 있습니다.

CMake는 최근까지 이 Ninja 문제로 가려졌던 순환 종속성 문제에 직면했습니다 . 이 문제가 수정되었다면 CMake 문제를 훨씬 더 빨리 발견했을 것입니다.