Godot: 빌드 시스템을 Meson 또는 다른 빌드 시스템으로 이동하는 것을 고려하십시오.

내가 이해하는 바에 따르면 빌드 시스템 도구는 다음을 제공해야 합니다.

• 교차 컴파일(동일한 호스트 플랫폼에서 가능한 모든 대상 플랫폼으로 컴파일).
  
  
  
  • "가능"이란 호스트가 허용한다는 것을 의미합니다(따라서 macOS 및 iOS는 Mac 컴퓨터에서만 가능하고 Linux에서는 OSXCross가 포함됨).
  
  
• 파일을 생성하는 방법(PO에서 번역, GLSL에서 셰이더 클래스, XML에서 문서 데이터).
  
  
  
  • SCons는 생성된 파일이 종속성임을 알고 있으므로 파일을 변경하면 관련 파일이 다시 빌드됩니다. 이것도 고려해야 합니다.
  
  
• 여러 대상 및 대상 내의 옵션(target=debug/release_debug/release, x86 또는 ARM과 같은 아키텍처, 32 또는 64비트).
• 추가 대상을 사용자 지정/활성화하는 옵션(gdnative 래퍼, 모노 글루 없음, 활성화/비활성화: 모듈, 드라이버, 더 이상 사용되지 않는 기능 등, 내장 코드를 사용하여 정적으로 컴파일하도록 라이브러리를 설정하거나 각각에 대해 시스템 라이브러리를 사용하도록 설정) 하나는 개별적으로).

나는 Meson을 모르지만 위의 모든 것을 제공한다면 괜찮을 것입니다 (내가 뭔가를 잊지 않았다면). 물론 누군가는 Meson에서 빌드 시스템을 다시 작성하는 극심한 고통을 겪어야 하고 도구와 빌드 시간이 SCons보다 Godot에게 효과적으로 더 낫다는 것을 보여주어야 합니다.

몇몇 제3자 의존성은 Godot로 컴파일되는 패치를 요구한다는 점에 유의하십시오. Wrap에 패치 지원이 있다는 것을 알았지만 패치는 다운로드할 수 있는 어딘가에 있어야 하는 것처럼 보이지만 여전히 저장소의 일부인 경우 관리하기가 더 쉽다고 생각합니다. 또한 일부는 전체 빌드에 적용해서는 안 되는 특수 컴파일 플래그가 필요합니다.

이러한 개념 증명은 매우 가치가 있다고 생각합니다.

• 새로운 빌드 시스템이 우리가 필요로 하는 모든 것을 처리하고 얼마나 잘 처리하는지 더 나은 아이디어를 제공합니다.
• 논의할 추상적인 데이터 대신 구체적인 정보를 제공합니다.

두 번째 점의 경우,이 방법은 우리가 고도 (Godot)에 대한 빌드 속도의 차이를 볼 수 있습니다, 우리는 얼마나 쉽게 (또는 더 복잡한) 우리의 빌드 스크립트가 될 볼 수 있습니다, 우리는 교육을 만드는 선택을보다 쉽게 차이를 대신 비교할 수 있습니다 제공할 수 있다고 생각하는 것을 기반으로 추측합니다.

--

자, 개인적으로 저는 이에 대해 찬성도 반대도 하지 않는다고 말해야 합니다. 그러나 전체 빌드 시스템을 변경하는 대신(또는 이전에?) 추구해야 할 더 낮은 성과가 있다고 생각합니다. 특히 이 중요한 시점에서 3.0과 첫 번째 패치가 최상의 형태로 유지되도록 최대한 많은 손이 필요합니다. 우리는 빌드 시스템을 개선하고 싶은 경우에, 나는 CI 빌드 시간과 모노 빌드 상황의 번거 로움보고 싶은데. (나는 이것이 akien 의 TODO/불만 목록에 있다고 생각합니까?)

또한 Windows에서 버그가 있는 병렬 빌드는 짜증나지만, 이는 개인적으로 수정되면 좋을 것입니다.

TL;DR:

• 나는 SCons 문서/리소스가 부족하다는 데 동의합니다. 빌드 스크립트가 쉬운 Python은 이를 어느 정도 상쇄합니다. IMO
• 새로운 기여자로서 Godot 빌드 시스템은 설정하기 가장 성가신 것 중 하나였으며 첫 번째 성공적인 컴파일 시간이 정말 짧았습니다.
• 차라리 3.0/3.1을 최대한 개선하는데 들인 노력을 봤으면 좋겠고, 안정화되면 이걸 생각해볼 수도 있겠 네요.
• 더 나은 CI 빌드 시간 및 더 쉬운 Mono 빌드가 더 중요할 수 있음

내 의견. :)

나는 3.0을 출시하고 다음 릴리스(3.0.1, 3.1)에 집중하는 것이 기록을 위해 이것보다 우선해야 한다고 절대적으로 믿습니다.
그것은 단지 다른 개발자 / 특히 기술에 정통한 최종 사용자의 이익을 위해 정말 이후 명 (buildsystems에 대한 작업을 같이하지 않는 이유는 알 - 중요 취소하지 않습니다, 그것은 DEVS '와 참여자의 삶을 쉽게하기 위해 보람 , 그러나 궁극적으로 최종 사용자의 행복이 목표입니다) 이 전체 "기회 비용"이 있습니다. 빌드 시스템 개선에 소요된 시간(또는 요청한 사람에 따라 손실/낭비)이 프로젝트 자체 개선에 사용될 수 있는 경우. (당신이 나와 같아서 어쨌든 C++ 쪽에서 실제로 일할 수 없다면.)

그리고 궁극적으로 SCons는 실제로 "그냥 작동"합니다. 대부분의 개발자에게는 아마도 충분할 것입니다. 따라서 이것이 결국에는 일어나기를 바라는 일이지만 3.1 또는 3.2에 대해서는 숨을 참지 않고 있습니다. 실제로 작업을 시작하기에 충분한 지원을 얻는다면.

이 모든 것이 말하지만, 진행 상황을 기꺼이 따르려는 사람들을 위해 이번 주 후반에 POC를 시작할 수 있습니다. 하지만 당분간은 이에 대한 풀 리퀘스트를 열지 않을 것입니다.

나는 실제로 SCons가 느리다고 생각하지 않으며 유연성(우리가 많은 이점을 취하는)은 아마도 다른 어떤 것과도 비교할 수 없을 것입니다. SCons는 또한 매우 입증되었으며 빌드를 망치지 않는다는 것을 알았습니다.

솔직히 말해서, 누군가 가 전체 빌드 시스템 (단순한 개념 증명이 아니라)을 재작성 더 간단하거나 (코드가 훨씬 적음) 훨씬 빠르다 는 것을 보여주지 않는 한, 저는 다른 어떤 것도 고려하지 않을 것입니다.

자, 개인적으로 저는 이에 대해 찬성도 반대도 하지 않는다고 말해야 합니다. 그러나 전체 빌드 시스템을 변경하는 대신(또는 이전에?) 추구해야 할 더 낮은 성과가 있다고 생각합니다.

이 변경 사항에 실제로 해로운 것은 아닙니다. 내 말은, 대부분의 Godot 기고자들은 여가 시간에 일하고 그들이 원하는 일을 합니다. @NullConstant 의 경우 "이 작업을 수행하거나 아무 작업도 수행하지 않음"(문제를 수정 하고 싶지 않다고 말하는 것이 아니라 실제 C++ 코드 기반으로 작업하고 익숙하지 않은 것에 대한 버그 사냥이 더 어렵다는 의미)인 것 같습니다. 이렇게 하는 것은 일반적으로 좋은 일입니다.

또한, "더 좋은 일이 있다"는 주장은 IMO에서 아무것도 하지 않는 방법입니다. 물론 아무것도 깨지지 않고 릴리스에 가까워지지 않을 것이라고 확신할 때까지는 아무 것도 병합 되지 않을 것입니다. 더 중요한 일이 있다는 데 동의하지만 이것이 시작될 수 없다는 것을 의미하지는 않습니다.

문제는 이 작업을 수행하는 사람이 혼자 이 작업을 수행해야 할 가능성이 높다는 것입니다. 물론 핵심 개발자가 특정 질문에 답변할 수 있지만 그 이상은 발생하지 않습니다. 이것이 SCons가 교체된 것으로 간주되지 않은 이유입니다. 지금까지 아무도 손을 더럽히는 것을 원하지 않았습니다. 전에 Bullet에 대해 말했듯이 누군가는 그것을 작동시키고 그것이 가능하고 더 낫다는 것을 증명해야 합니다. 그렇지 않으면 우리는 현상 유지에 머물 것입니다.

그래도 SCons는 느리다고 생각합니다. 그다지 느리지는 않지만 진행 상태 및 캐시와 같은 문제로 인해 재구축이 느려지므로(디스크 I/O를 사용하여 캐시에서 읽는 것이 느려짐) 재구축할 때 해당 기능을 비활성화합니다. 작업을 시작하는 데 약간의 시간이 걸리고 그 후에는 상당히 빠릅니다.

Meson이 훨씬 더 빠를지는 모르겠지만 누군가가 기꺼이 시도한다면 나는 반대하지 않습니다.

오, 물론, 누군가가 시간을 들여서 전환을 보증할 만큼 충분히 큰 개선 사항을 보여 준다면 저는 전적으로 찬성합니다. :)

내가 말했듯이, 나는 C++ 버그를 사냥하거나 그 전면에 새로운 기능을 추가하는 일을 다룰 준비가 되어 있지 않으므로 대신 이 일을 하는 것이 좋습니다.

나는 이것이 나(및/또는 미래에 이 일을 하는 다른 사람)에게 도달할 수 있는 매우 깨끗하고 이중적인 목표를 제공한다고 생각합니다.

• Godot가 어떤 형태로든 Meson으로 컴파일하도록 하세요.
• 현재 SCons가 가능한 것처럼 쉽게 만들 수 있습니다(속도를 개선하여).

그리고 나는 SCons의 속도가 끔찍할 정도로

가장 큰 문제는 아마도 셰이더와 같은 코드를 자동 생성하기 위해 파이썬 빌드 스크립트를 교체하는 것입니다. meson에 그런 기능이 있는 것 같지 않습니다.

Meson을 대안으로 제공하는 것은 개선 사항일 수 있습니다. 우리는 볼 것이다.

그것은 대안이 되어서는 안 되며, 분명히 더 나은 경우 그 대안으로 이동하거나 제공하지도 않습니다. 두 개의 빌드 시스템을 지원해야 하는 것은 미친 짓입니다.

맞습니다. 공정합니다.

나는 앞으로 며칠/몇 주에 걸쳐 그것을 해킹하기 시작할 것이고, 이것이 아무 데나 진행되는지, 그것이 진정으로 추구할 가치가 있는 노력인지 여부를 확인합니다.

(벤치마크와 같은) 표시할 수 있는 것이 있으면 다시 보고하겠습니다.

meson이 아니라 앞으로 몇 주 안에 msvc에서 Windows 64비트용 godot under bazel을 빌드하는 데 필요한 것을 확인하기 위해 테스트를 할 것입니다.

Bazel은 더 짧은 빌드 설명과 더 빠른 빌드가 장점인 또 다른 시스템입니다. 또한 Google에서 유지 관리하므로 아무데도 가지 않습니다.

어쨌든, 나는 그것을 확인할 수는 없지만 Godot를 구축하는 데 소요되는 계산 시간의 99%가 컴파일러에서 소비될 가능성이 매우 높습니다. 따라서 빌드 소프트웨어의 오버헤드가 전혀 없다고 해도 빌드 시간이 1% 감소합니다. 더 적은 코드와 더 많은 안정성을 허용하지 않는 한(또는 내가 틀렸다고 판명된 경우 :)) 5% 감소도 가치가 없습니다.

깨끗한 클론의 원시 빌드 속도의 경우 큰 차이가 있는지 의심됩니다. 그러나 재구축 속도를 고려하면 중요할 수 있습니다. SCons는 항상 내가 새 커밋을 가져올 때 변경되지 않은 많은 것을 다시 빌드합니다(특히 OpenSSL 및 Bullet은 모두 큰 라이브러리이고 빌드하는 데 시간이 걸립니다).

전에 말했듯이 SCons는 시작하는 것이 느립니다(실제로 컴파일을 시작하기까지 몇 초가 걸립니다). 무시할 수 있는 전체 소스를 빌드하고 있지만 라인만 변경하고 테스트를 위해 컴파일하는 경우 워크플로를 크게 개선할 수 있습니다(IMO는 빌드 시스템에서 가장 중요한 것입니다. 코드로 작업하는 사람들을 도우십시오) . 따라서 10분 빌드에서 5초 감소는 관련이 없지만 10초 빌드에서 5초 감소는 주요 개선 사항입니다.

그러나 이와 관련하여 변경 사항이 작동하는지 증명하려면 많은 테스트를 거쳐야 한다는 데 동의합니다. @reduz가 말했듯이 SCons는 빌드를 엉망으로 만들지 않았으며 이는 고려해야 할 사항입니다.

Bazel은 더 짧은 빌드 설명과 더 빠른 빌드가 장점인 또 다른 시스템입니다. 또한 Google에서 유지 관리하므로 아무데도 가지 않습니다.

"Google이 중단한 것"이라는 Wikipedia 범주가 증가하고 있습니다. :)

@mhilbrunner 아니요, 여전히 유지 관리됩니다 https://github.com/bazelbuild/bazel

그들의 요점은 구글이 그것을 만들었다고 해서 그것이 오랫동안 존재할 것이라는 의미는 아니라는 것입니다.

우리는 게임 개발을 위해 C#을 받아들였기 때문에 Cake 와 같은 것을 시도해 볼 수도 있습니다. 나는 그것을 직접 시도하지 않았으므로 그것에 대한 당신의 생각이 궁금합니다. 한 가지는 적어도 스크립트가 Python보다 더 빠르게 실행됩니다.

우리는 게임 개발을 위해 C#을 받아들였기 때문에 Cake 와 같은 것을 시도해 볼 수도 있습니다.

Godot가 대부분 C++ 프로젝트이고 C# 지원 없이 컴파일될 수 있다는 점을 고려하면 Godot를 컴파일하기 위해 Mono 설치를 요구하는 것이 좋은 생각인지 잘 모르겠습니다.

Meson 또는 CMake(Ninja 생성기 포함)가 제공하는 성능 수준은 Godot의 목적에 충분해야 합니다.

@Calinou 당신이 맞을 것입니다. 비록 모두가 C#의

편집하다:

모노 프레임 워크를 필요로 명확히하기는 소위 AAA 게임 엔진이 방법은 더 많은 디스크 공간이 필요하기 때문에 고도 (Godot)가, 나에게 나쁜로 소리가 나지 않는다 구축하기 위해 설치되어야합니다 :

• 고도 <50MB
• Mono 지원이 있는 Godot (<50MB) + Mono Framework (~350MB) = ~400MB
• 언리얼 ~20GB
• 유니티 ~10GB
• 크라이엔진 ~8GB

게다가 기본적으로 편집기에서 Mono 지원을 하드코딩하고 런타임에 C# 스크립팅을 지원할지 여부를 감지하고 Mono 프레임워크 또는 적절한 내보내기 템플릿을 요청하는 일부 논리를 가질 수 있습니다.

나는 CMake를 좋아하고 meson은 멋지게 보이지만 http://www.rojtberg.net/1481/do-not-use-meson 기사에 동의하는 경향이

저는 Godot를 Meson으로 옮기기 위한 발놀림을 하는 데 매우 관심이 있습니다. 현재 제가 Godot에 기여하는 것을 막고 있는 유일한 것(그리고 그것을 사용하는 것)은 Scons입니다. 나는 몇 년 전에 그것을 사용해야 했고, 내 평생 동안 이보다 더 고통스러운 점진적 개발 경험은 없었다.

위에 링크된 기사에는 CMake가 이미 존재하고 우리는 그것을 사용해야 한다고 주장하는 많은 주장이 있습니다. Meson의 빌드 파일은 읽기가 매우 쉽고 Python과 유사한 구문을 사용합니다. 전환이 빠를 수 있습니다. 이 스레드에 게시하는 내용은 풋워크가 완료되면 pull 요청이 병합에 대해 고려될 수 있습니까?

이 스레드에 게시하는 내용은 풋워크가 완료되면 pull 요청이 병합에 대해 고려될 수 있습니까?

고려되지만 SCons보다 유리한 것으로 입증되어야 합니다.

CMake를 사실상 표준이 아닌 또 다른 빌드 시스템으로 생각하면 너무 많은 옵션이 생깁니다. 왜 SCons보다 중간입니까? 아니면 bazel/buck도 괜찮은 도구입니까? 그러나 내가 CMake에 찬성하는 가장 큰 주장은 해당 생태계를 지원하기 위해 구축된 도구입니다. Clang 컴파일 데이터베이스, 여러 운영 체제에 대한 패키징 지원 등. 내가 들은 유일한 유효한 단점은 잘못된 구문과 문서이지만, 이것으로 내 입장을 바꿀 만큼 충분히 강력하지 않습니다.

왜 SCons보다 중간입니까?

Meson은 증분 개발에 훨씬 더 빠른 닌자 파일을 생성합니다. 또한 Windows에서는 어떤 종류의 Visual Studio 경로 조작도 수행할 필요 가 없습니다. Meson은 기본적으로 작동합니다. scons보다 meson을 사용하면 특히 Visual Studio를 사용하려는 사람들의 경우 대상 창의 오버헤드를 많이 줄일 수 있습니다.

아니면 bazel/buck도 괜찮은 도구입니까?

bazel과 buck이 모두 Java로 작성되었다는 점을 감안하면(android를 대상으로 하는 경우에만 종속성 godot가 있고 기술적으로 NDK 만 사용할 수 있는 경우 pip install meson 통해 meson(및 ninja)을 쉽게 설치할 수 있습니다.

Clang 컴파일 데이터베이스

Meson은 ninja에 내장된 기본 기능이므로 기본적으로 이를 지원합니다.

여러 운영 체제에 패키징 지원

Meson도 이를 지원하며 적절한 경우 pkg-config에 크게 의존합니다.

내가 들었던 유일한 유효한 단점은 잘못된 구문과 문서입니다.

Meson은 변수, 객체 및 내장 함수에 의존하는 매우 파이썬과 유사한 구문을 가지고 있습니다. 제 생각에는 글을

my_meson_list = ['x', 'y', 'z']
message(my_meson_list)

대

set(MY_CMAKE_LIST "x;y;z")
message(STATUS ${MY_CMAKE_LIST})

특히 cmake가 때때로 대소문자를 구분하고 그렇지 않은 경우를 고려할 때 훨씬 쉽습니다. 생성기 표현식을 시작하면 매우 복잡해질 수 있습니다.

# In one file
set(USE_STD_CXX11 "-std=c++11")
set(USE_STDLIB_LIBCXX "-stdlib=libc++")

# Possibly elsewhere
set(LIBCXX $<BOOL:${CAN_USE_STDLIB_LIBCXX}>,$<BOOL:${BUILD_WITH_LIBCXX}>)
set(NO_RTTI $<BOOL:${CAN_USE_NO_RTTI}>,$<BOOL:${DISABLE_RTTI}>)

# Later on...
target_compile_options(my-exe
  PUBLIC
  $<$<BOOL:${CAN_USE_STD_CXX11}>:${USE_STD_CXX11}>
  $<$<AND:${LIBCXX}>:${USE_STDLIB_LIBCXX}>
  $<$<AND:${NO_RTTI}>:${USE_NO_RTTI}>
  # Oh yeah, you're gonna want more of these, because you can't trust compiler interfaces
)

# Generator expressions mean you can't follow the flow of the build to see what is called and defined where. This is a completely valid use of CMake.
check_cxx_compiler_flag(${USE_STDLIB_LIBCXX} CAN_USE_STDLIB_LIBCXX)
check_cxx_compiler_flag(${USE_NO_RTTI} CAN_USE_NO_RTTI)

등가 중간자는 다음과 같습니다.

cxx = meson.get_compiler('cpp')
# This is an extremely simplified approach. One can do a different option when dealing with MSVC and gcc support.
args = compiler.get_supported_arguments('-std=c++11', '-stdlib=libc++')
add_project_arguments(args)

그건 그렇고, 나는 모든 C++ 빌드 시스템 중에서 Meson이 가장 끔찍 하다는 점에 주목해야 한다고 생각합니다. 그것의 사용에 반대하는 주장은 웹 만화의 그림인 경향이 있고, 어떤 사람들은 CMake가 가장 많이 사용되는 방식에 대해 손을 흔드는 경향이 있으므로, "이봐 적어도 CMake는 autotools가 아닙니다"라고 처리해야 합니다.

그러나 무엇보다도(특히 gdnative로 Godot를 사용하는 사람들에게 이것은 정말 중요한 일이라고 생각합니다) Meson은 기본적으로 미리 컴파일된 헤더를 지원합니다. CMake는 그렇지 않습니다(그리고 cotire를 사용하여 빌드를 해킹하면 가치보다 더 많은 문제가 발생할 수 있습니다).

이것이 gdnative 사용자의 빌드 속도를 얼마나 높일 수 있는지 말할 수는 없지만 gcc 및 msvc에서 상당한 향상이 될 것입니다(최소한 msvc에서 성능 향상은 불가피합니다). Godot에서 발견되는 아주 적은 양의 템플릿 코드에 대해 extern template 사용을 추가하면 반복 및 증분 빌드에 중요한 상당한 빌드 시간 개선을 볼 수 있습니다.

Meson은 닌자 파일을 생성하므로 증분 개발에 훨씬 더 빠릅니다.

CMake는 기존 Makefile 대신 Ninja 빌드 파일을 생성할 수도 있습니다. 이것은 -G Ninja 를 명령줄에 전달하여 수행됩니다. 내가 시도한 대부분의 프로젝트에서 꽤 잘 작동하며 전체적으로 약간 더 빠릅니다(게다가 기본적으로 모든 CPU 스레드를 사용합니다).

Meson은 내가 본 원시 성능 비교에서 여전히 이기고 있지만 이것은 Meson과 CMake 성능 간의 격차를 줄이는 데 확실히 도움이 됩니다.

예, 그러나 CMake는 자동으로 닌자를 설치하지 않으며 기본 생성기가 아닙니다. 내 경험상 CMake의 대부분의 시간은 프로젝트를 구성하는 데 사용되며 최신 버전의 CMake는 성능이 크게 향상되었지만 모든 사람이 최신 CMake를 사용하는 것은 아닙니다.

아주 철저합니다! 빌드 시스템에서 중요하게 생각하는 기능에 대한 좋은 아이디어가 있어서 기쁩니다. 나는 여전히 프로젝트가 의존할 수 있는 C++ 세계에서 표준 빌드 시스템이 있어야 한다고 생각합니다. 나는 meson이 자체적인 것이 아니라 CMake 트랜스파일러였으면 합니다.

나는 여전히 프로젝트가 의존할 수 있는 C++ 세계에서 표준 빌드 시스템이 있어야 한다고 생각합니다.

저를 믿으세요. 저보다 더 원하는 사람은 없습니다. 나는 일종의 빌드 시스템 쓰레기 고블린이 되었고 CppCon에서 그들에 대해 이야기하기까지 했습니다. 나는 불행히도 (또는 다행스럽게도?) 거의 집착의 지점에 이르기까지 빌드 시스템에 대해 많은 관심을 가지고 있습니다. :)

이 말을 하고 싶지만 Windows에서 Godot를 오랫동안 빌드할 때마다 Python이 일관되게 내 CPU의 15% 이상을 차지한다는 사실에 주목했습니다. 시작이 느릴 뿐인지 의심스럽습니다.

누가 meson으로 만든 작은 프로토타입 Godot 엔진을 만들까요? 나는 bazel에 대한 작은 테스트를 만드는 지점에 도달하지 못했습니다.

Godot의 2D 전용 빌드는 모든 옵션을 비활성화한 상태에서 테스트하기에 충분해야 합니다.

내가 직면한 첫 번째 장애물은 core/make_binders.py였습니다. 이것은 Godot가 사용하는 자동 생성 코드입니다.

빌드 시스템 Bazel에서 초기 프로토타입을 만들었지만 다른 문제에서 설정에 대해 논의하겠습니다. https://github.com/godotengine/godot/issues/18518

일주일 동안 시간이 없지만 다른 사람들은 Bazel BUILD에서 확장할 수 있습니다.

Lol bazel은 어떻게 참여하게 되었나요?

다른 빌드 시스템으로 전환할 수 있는 기회가 한 번 있을 수 있으므로 가능한 최상의 옵션을 찾아야 하지 않을까요? 나는 Cake vs Bazel vs Scons 비교 차트를 보는 데 관심이 있지만, 그 테스트를 위한 풋워크를 수행하기 위해 Cake에 대한 경험이 전혀 없다는 것을 인정해야 합니다.

@rraallvv 는 케이크 또는 CMake를 의미합니까?

@isaachier 내 나쁜, 나에 대해 얘기했다 www.cakebuild.net , 나는 그것에 대해 죄송합니다,보다 구체적인되어 있어야합니다.

C# 전용 아닌가요?

@isaachier 저는 잘 모르겠습니다. SCons가 Python으로 작성되고 C++를 지원하는 것처럼 케이크가 가능하다고 가정했습니다. 그럼에도 불구하고, 나는 방금 그들의 gitter chat 에서 물었습니다. 여기에 답변을 다시 게시하겠습니다.

기록을 위해 @rraallvv 주요 빌드 시스템을 나란히 비교하는 아이디어는 좋은 아이디어라고 생각합니다. 다음은 내가 온라인에서 상당히 편견이 없다고 생각하는 것입니다(빌드 시스템 개발자가 작성하지 않음): https://carlosvin.github.io/posts/choosing-modern-cpp-stack , https://www.reddit. com/r/cpp/comments/6euc7b/build_systems_bazel_buck/die6g1y/ , https://stackoverflow.com/a/12022652/1930331.

내 개인적인 의견:

• CMake : 꽤 못생긴 언어이지만 어디에나 있고 거의 업계 표준입니다.
• SCons : 느리고, 오래되고, IDK 상태입니다. 파이썬을 사용합니다.
• meson : 엄청나게 느리지 않은 새롭고 멋진 Python 기반 빌드 시스템입니다. 주요 단점은 궤도입니다. 이것이 주간 빌드 시스템의 또 다른 특징인지는 확실하지 않습니다.
• Autotools : 고대, 도구 지원 없음(예: Clang 자동 완성 지원 또는 정적 분석을 위한 컴파일 데이터베이스). Windows 지원이 없습니다. 무슨 수를 써서라도 피하십시오.
• bazel : Google 패키지 관리자/빌드 시스템이 하나로 통합되었습니다. Hunter 와 같은 플러그인으로 CMake에 많은 것을 추가하지 않습니다. 또한 Google 소프트웨어는 일반 대중이 아닌 Google이 필요로 하는 것에 초점을 맞추는 경향이 있습니다. 장기적인 궤적을 측정하기에는 너무 새롭습니다.

C++에 대한 사실상의 표준을 원하고 CMake가 현재 가장 큰 "시장 점유율"을 갖고 있기 때문에 기회가 있을 때마다 CMake를 추진하려고 합니다.

@isaachier 해당 정보를 공유해 주셔서 감사합니다. C++에서 스크립팅을 지원하는 빌드 시스템이 없기 때문에 C#을 추진하고 있습니다. 어리석게 들릴 수 있지만 누군가가 아직 그렇게 하지 않은 이유를 모르겠습니다. 예를 들어 이 C++ REPL 은 다음 단계로 이동하여 어느 것이 더 낫고 더 빠른지에 대한 논쟁을 끝내고 싶다면 빌드 시스템에 사용할 수 있습니다.

이해가 안 돼요. C++는 아마도 끔찍한 빌드 언어일 것입니다. 느림은 사용된 스크립팅 언어의 세부 사항이 아니라 내부 빌드 시스템 코어 AFAIK와 더 관련이 있습니다.

@isaachier 내 생각에 SCons는 Python으로 작성되었기 때문에 너무 느리지만 누군가가 전체 빌드 시스템을 C++로 이식하는 작업을 수행하고 해당 빌드를 실행하기 위해 C++ 스크립트를 JIT 컴파일하게 하면 훨씬 더 많을 것입니다. 더 빠르게. 아마도 모든 빌드 시스템이 마찬가지일 것입니다.

좋은 생각이지만 meson은 대부분의 계정에서 느린 것으로 간주되지 않지만 Python으로 작성되었습니다.

GNOME 프로젝트가 현재 meson을 위해 autotools를 포기하고 있기 때문에 meson이 이번 주의 풍미가 될지 의심됩니다.

또한 Scons는 파이썬으로 작성되어서가 아니라 빌드를 실행하기 때문에 느립니다. make 또는 ninja와 같은 직접 빌드 시스템이지만 정의를 위해 막대한 양의 XML을 사용하고 많은 양의 코드가 실제로 XSLT 변환에 불과합니다.

반면 Meson은 빌드 스크립트를 실행하여 종속성 트리를 생성한 다음 이를 닌자 파일에 덤프합니다. 닌자가 빠르기 때문에 메손이 빠릅니다. 또한 CMake와 같이 Meson에서 모든 것이 문자열인 것은 아닙니다.

마지막으로, C++로 스크립팅할 수 있는 개발 빌드 시스템이 몇 개 있다는 점에 유의해야 합니다. (저는 실제로 그 중 하나를 작성하고 있습니다.) 그러나 Godot에 아직 존재하지 않는 빌드 시스템으로 이동하도록 요청합니다( 그리고 더 나쁜 것은 나 자신이 쓰고 있다는 것)이 겸손하지 않은 내 의견으로는 약간 오만합니다 ;)

나는 또한 현재 개발 워크플로에서 파이썬이 필수라는 점을 되풀이하고 싶습니다. 메손도 마찬가지입니다. 그리고 이것은 파이썬의 pip 도구를 호출하는 것처럼 간단하게 meson으로 이동합니다.

나는 SCons도 느리다고 생각하지 않는다는 @reduz에 완전히 동의합니다.

@slurps-mad-rips가 말했듯이 :

Scons는 python으로 작성되어서가 아니라 빌드를 실행하기 때문에 느립니다.

남자 scons:

scons는 생성될 수 있는 동시 작업 수를 인수로 사용하는 -j 옵션을 통해 여러 대상을 병렬로 구축하는 것을 지원합니다.
scons -j 4

나는 8c16t가 있는 CPU를 가지고 있으므로 "scons p=x11 -j 18"을 사용하는 것이 매우 빠릅니다.
"scons p=x11"을 기본 설정인 "-j 1"로 사용하는 것보다 10배 빠릅니다.
2018년에 싱글 코어 CPU가 있는 사람이 있습니까?
CPU가 완전히 작동하도록 하십시오.
시도해 주세요.

모든 사람이 이렇게 큰 CPU를 가지고 있는 것은 아니지만 더 중요한 것은 meson(글쎄, 닌자)이 증분 재컴파일에서 훨씬 더 빠르다는 것입니다. Scons는 기본적으로 MD5 해시 합계를 수행하여 파일이 변경되었는지 확인합니다. Godot는 MD5-타임스탬프 설정을 사용하는데, 이는 타임스탬프가 변경된 경우에만 파일을 해시한다는 것을 의미합니다. 여전히 웃기다.

더 나은 것을 증명하는 가장 좋은 방법은 새로운 것을 작성하고 보는 것입니다 :)

Scons는 많은 사람들, 특히 -j 1 이상의 문제에 직면하는 Windows 사용자에게 빠르지 않습니다.

@slurps-mad-rips 프로젝트에 따라 다릅니다. 닌자는 속도를 너무 과장한 것 같습니다. 이 문서를 참조하십시오: http://david.rothlis.net/ninja-benchmark/. 소스 파일을 계산하는 것이 가장 좋은 방법인 것 같습니다. <20K이면 큰 차이가 없습니다.

@isaachier 그 벤치마크는 ninja와 scons가 아니라 make와 ninja 사이에 있으므로주의를 기울이고 싶지 않다면 용서해야합니다. ;)

더 나은 것을 증명하는 가장 좋은 방법은 새로 작성하고 보는 것입니다 :)

동의합니다. 자전거를 흘리는 것은 의미가 없습니다. 더 나은 빌드 시스템에 대한 의견이 있으면 이를 구현하고 더 낫다는 것을 증명하세요. 그렇지 않으면 이것은 의견에 대한 토론이며 아무데도 이끌지 못할 것입니다. @fire 는 이미 https://github.com/godotengine/godot/issues/18518.

@slurps-mad-rips ya 완전히 다른 주제, SCons가 아닙니다. 나는 단지 make vs. ninja가 미친 차이가 아니라는 것을 의미했습니다.

약간의 업데이트: meson으로 이동하는 것을 포기합니다. 단편적이었고 빌드 파일이 약간 더 읽기 쉬웠지만 현재 시스템을 최신 상태로 유지하는 것은 scons를 meson으로 옮기는 대신 내 (지금은 드물고 공급이 부족한) 자유 시간의 대부분을 보내는 곳입니다.

현재 많은 코드와 작업이 scons 스크립트에 직접 배치되어 다른 빌드 시스템으로 이동하기가 더 어렵습니다. 내가 주장하는 것이 있다면 scons에서 코드를 생성하는 기존 python 스크립트를 분리하는 데 시간을 소비해야 한다고 주장합니다. 이렇게 하면 meson, cmake 또는 bazel과 같은 다른 빌드 시스템으로 훨씬 쉽게 이동할 수 있기 때문입니다.

모든 코드 생성을 제거하기 위해 패치가 병합된 것이 좋습니다. https://github.com/godotengine/godot/pull/17595 포기하지 마세요!

SCons 프로젝트 공동 관리자가 여기에 있습니다. 몇 가지 참고 사항:
1 - SCons는 활발히 개발 중이며 Github으로 마이그레이션한 이후로 끌어오기 요청 비율이 증가하고 있습니다.
2 - null 증분 빌드 시간의 약 50%를 담당하는 SCons의 몇 가지 특정 부분을 확인했으며 이를 해결하기 위해 적극적으로 노력하고 있습니다. (Subst 기능)
3 - SCons 3.0에서 Python 3.5+(2.7.x 포함)를 지원하기 시작했습니다.
4 - N개의 다른 빌드 시스템으로 이식하려고 시도하는 대신 SCons를 개선하는 데 약간의 시간을 기여하는 것이 개발자 시간을 더 효과적으로 사용할 수 있다고 제안하겠습니다.
5 - 우리는 3.0.0 및 3.0.1에서 릴리스된 성능 개선의 일부 낮은 행잉 과일을 식별하고 해결했습니다. 이전 버전을 사용하는 경우 null 증분 빌드가 5-15% 느려질 수 있습니다. (파이썬 2.7.x 가정)

항상 그렇듯이 SCons 프로젝트는 SCons를 사용하여 문제가 발생하는 프로젝트를 도울 준비가 되어 있고 기꺼이 도울 것입니다.

SCons 및 Godot에 대한 일부 "통계".

나는 오늘날 우리가 "모두" 사용하는 프로세서(i7s)보다 2.4GHZ(및 사이클 수당 더 낮은 명령어)를 가진 2008년 정도의 4코어 CPU인 Q6600을 사용했습니다(그리고 여전히 사용하고 있습니다).

Q6600에서 빌드는 3분에서 5분(또는 그 이상이지만 정확한 숫자는 그다지 중요하지 않음)이 소요되었으며, 그 중 SCons가 종속성 및 항목 트리를 구문 분석하는 데 ~35-40초가 소요되었습니다(준비 작업)... 따라서 80%의 시간이 cl.exe(MSVC 컴파일러) 프로세스를 반복해서 실행하는 데 소요되었습니다.

따라서 성능 및 최적화 측면에서, SCons(SCon이 아닌 실제로 파이썬)에는 예상보다 더 많은 시간이 소요되는 끔찍한 프로세스 호출 시스템이 있거나 다른 도구가 프로세스당 하나의 파일을 컴파일하지 않고(현재 SCons와 같이) 1 하나의 파일당 프로세스 오버헤드는 중요합니다(저는 cl.exe 컴파일 내부 및 시작 오버헤드에 대한 전문가가 아닙니다). 더 빠른 빌드 시스템이 생성할 수 있는 유일한 성능 최적화는 아마도 종속성 트리 단계 구축 및 복잡성을 위한 기타 준비 작업일 것입니다. .

따라서 우리는 5분 빌드 중 35-40초를 최적화하고 있습니다(i7에서는 현재 3분 멀티 코어 빌드에서 20초 단일 코어 설정 단계를 최적화하고 있습니다).

요약하자면, 제 기억이 맞다면 3~5분이면 실제로 4코어 멀티코어 빌드이고 단일 코어 빌드에는 약 10분이 걸립니다. 테스트를 다시 시작해야 합니다...

따라서 SCons를 "최적화"한다는 것은 빌드 시작의 처음 35초를 다소 최적화하는 것을 의미합니다...

그것은 SCons 대 다른 더 빠른 빌드 시스템과 관련하여 "최적화"에 관한 것입니다... 모든 obj 파일에 대해 단일 cl.exe를 호출하는 것을 피하여 실제 컴파일을 약간 최적화할 수 있지만 이는 다음과 같은 경우에만 가능합니다. 프로세스 오버헤드가 상당합니다(HDD가 항상 실제 IO 병목 현상이 되는 것이 두렵습니다(CPU가 아님). 이는 SSD 없이는 피할 수/완화할 수 없음)

위의 모든 단락은 "전체 빌드"를 고려합니다. 즉, SCons는 모든 것이 이미 빌드되고 엄격한 일관성 검사를 통과하면 "치트"하므로 단일 파일을 변경하면 실제로 "단일 파일"을 컴파일한 다음 모든 것을 다시 링크하여 "전체 빌드"를 다소 증분 빌드). 그러나 이것은 35-40초의 완전한 종속성 트리 사전 계산이 필요합니다...

따라서 "증분 빌드"는 내 기존 컴퓨터에서 약 45초이며 2년 전 멍청한 놈이었을 때 CPU 바운드일 것이라고 생각했지만 실제로는 IO 바운드일 수 있습니다(HDD에서 수천 개의 파일 확인 ) 전체 종속성 스윕/트리 재구축의 경우... 따라서 IO 바인딩된 경우 "더 빠른 buidlsystem"이 해당 문제를 해결할 수 없습니다...

2년 전의 내 해킹 아이디어는 파일 시스템 "감시자"를 SCons에 연결하고 SCons가 단일 변경된 파일을 실행 및 재컴파일하도록 한 다음(자동으로 종속성이므로) 모든 것을 다시 링크하도록 하는 것이었습니다... 비록 연결이 여전히 전체 종속성 스윕을 실행할 수 있다는 것을 오늘 깨달았지만... 즉, 종속성 트리 스윕/재구축은 옵션으로 종료될 수 있으며 SCons는 캐시된 dep 트리를 사용합니다... 약 15-20개를 절약합니다. 35초 사전 계산 단계의 초(처음 15초는 피할 수 없는 것처럼 보임) 비록 그것이 SCons처럼 항상 "완벽한" 빌드를 보장하지 않을 수 있지만(개발의 증분 빌드에는 중요하지 않을 수 있지만... 속도가 가치있는 절충안).

이제 npm 및 npm watch... 또는 현재 익숙하지 않은 다른 시스템을 통해 해킹할 수 있다는 충분한 지식을 얻었습니다. 하지만 그건 나중에, 그리고 시간이 있을 때(현재는 아님)입니다.

이것은 좀 길어지므로 여기서 끝내겠습니다. 하지만 이 단락의 요점은 제가 좋아하는 것처럼 누군가를 낙담시키기보다는 (빌드 시스템에서 작업하는 것을 좋아한다면 계속하십시오) "통계적" 정보를 제공하는 것입니다. Godot의 SCons에서 몇 가지를 수정했습니다. 여기 계신 분들께 유용한 정보가 되었기를 바랍니다.

내 통계를 복제/재실행하려면 통계 정보(타이머 항목)를 켜고 종속성 재확산을 끄는 방법을 찾을 때까지 SCons 문서를 탐색하십시오("사전 계산"의 처음 20~30~35초). )...

또는 약간 덜 수동적인 솔루션의 경우, 다음으로 생성된 자동화된 VS 프로젝트에 타이머 디버깅 정보가 이미 있어야 합니다(편집: 확률이 아닙니다. 누군가 vs 프로젝트 생성에 대한 달콤한 업데이트처럼 보이는 작업을 수행했습니다. 이 단락은 오래된 정보일 수 있음). SCons(SConstruct 파일 끝)... godot 웹사이트의 "Windows 컴파일 튜토리얼"에서 VS 프로젝트를 생성하는 방법에 대한 정보를 찾을 수 있습니다. 그런 다음 VS에서 SCons를 실행할 수 있습니다. Godot 3에서 테스트하지는 않았지만 생성된 프로젝트가 여전히 작동해야 한다고 생각합니다... 옵션이지만 > log.txt에 scons를 추가하는 것도 또 다른 옵션입니다(등) ...

누군가 이 정보가 도움이 되었기를 바랍니다.

@Griefchief 조금 정리

실제로 "null 증분 빌드"(실제로 다시 빌드할 필요는 없지만 scons는 전체 종속성 트리를 처리하여 이를 보장해야 함)가 우리가 작업 중인 경우입니다.

일부 프로파일링에서는 명령줄(모든 대상이 변경되지 않았는지 확인하기 위해 수행해야 함) 처리의 일부 비효율성을 지적했습니다. 그 대부분은 Subst() 논리입니다. 이것은 약간의 까다로운 코드이며 지금까지 더 간단하고 안전하지만 끔찍하지 않은 효율적인 방식으로 구현되었습니다.

또 다른 핫스팟은 현재 cpickle로 구현되고 항상 전체적으로 읽고 쓰는 sconsign 파일을 읽고 쓰는 것입니다. 속도를 높이거나 더 증분하는 방법에 대한 몇 가지 아이디어가 있습니다. 어쨌든 개선을 위해 향후 릴리스를 시청하십시오.

참고로 MSVC_BATCH를 시도하여 Windows 빌드 속도가 빨라지는지 확인할 수 있습니다.

MSVC_BATCH
true 값으로 설정하면 SCons가 Microsoft Visual C/C++ 컴파일러를 호출할 때 개체 파일의 컴파일을 일괄 처리해야 함을 지정합니다. 동일한 출력 디렉토리에 대상 파일을 생성하고 동일한 구성 환경을 사용하여 SCons에서 구성된 동일한 소스 디렉토리의 모든 소스 파일 컴파일은 컴파일러에 대한 단일 호출로 빌드됩니다. 개체 파일이 빌드된 이후 변경된 소스 파일만 각 컴파일러 호출에 전달됩니다($CHANGED_SOURCES 생성 변수를 통해). 개체(대상) 파일 기본 이름(.obj 제외)이 소스 파일 기본 이름과 일치하지 않는 모든 컴파일은 별도로 컴파일됩니다.

@bojidar-bg 예, 예, 실제로 증분 빌드에 대해서도 이야기하고 있었습니다. 팁 감사합니다 :D

@bdbaddog 안녕하세요 baddog, 귀하의 정보를 위해 실제로 귀하의 의견을 보기 전에 이 큰 코멘트를 작성했습니다. 그래서 실제로 귀하의 코멘트에 있는 어떤 것도 구체적으로 언급하지 않습니다... 그러나 귀하는 " 우려" 우리가 동시에 의견을 작성하는 동안 나는 (사실상 다른 사람들을 위한 정보를) 가지고 있었습니다...

그리고 나는 당신의 시간을 "낭비"하고 싶지 않았기 때문에 당신에게 핑을 치고 싶지 않았습니다. 그냥 매우 바쁘다))

여기에 입력해 주셔서 감사합니다!

@bdbaddog BD, 지원을 제공하고 있기 때문에 여기에 질문할 수 있습니다.

npm watch를 파일 시스템(godot의 소스)에 연결하고 정확히 어떤 파일이 변경되었는지 알면 SCons에 어떤 이점이 있습니까?

이제 npm watch를 통해 scons를 실행하고 파일을 푸시할 수 있습니다...

scons [godot 옵션] /file/that/was/changed.

이것은 분명히 Godot의 전체 dep 트리를 피하면서 그 파일을 재컴파일할 것입니다. 옳은? 이제 dep tree traversal은 20초가 걸리지 않지만 1개 미만의 확률로 발생하지만 1개의 업데이트된 .obj 파일(또는 그 이상, 변경 사항에 따라 다름)을 얻습니다. 실제로 하나의 파일에 대해 전체 godot dep 트리를 거치지 않습니까? 나는 이 예제에서 더 적은 dep tree traversal에 이점이 있습니까?

이제 내가 이점이 있고 모든 것을 다시 연결하려면 "단순한" 연결 단계를 위해 전체 트리 탐색이 필요합니까?

나는 이 사용 사례가 현재 Scons에서 지원되지 않을 수도 있다는 것을 이해하지만(모든 것을 다시 연결하기만 하면 됨), 실용적이고 이론적인 관점에서 모두 묻고 있습니까? 캐시된 dep 트리가 "dep tree를 사용하지 않음" 옵션과 함께 재사용할 수 있다는 것을 알고 있습니다(잊어버렸습니다. 2년이 지났습니다). 일부 사용 사례에서는 작동하며 해당 사용 사례는 새 파일이 추가되지 않았습니다. ? (npm watch는 새 파일 추가에 대해 경고할 수 있고 내가 감지하면 전체 깊이 트리 새로 고침을 수행할 수 있습니다. 다시 말해 "깊이 트리 일관성 보장"을 npm watch와 같은 파일 감시기로 다시 푸시하고 자동화합니다. 사용자가 npm watch와 같은 프로그램에 수동으로 수행한 "종속성 캐시 사용" 옵션을 입력하면 프로그램이 사용자가 아닌 일관성에 대해 걱정하게 하고 사용자가 파일을 저장한 순간 "실시간"으로 수행합니다. 파일, scons가 작업을 수행하는 데 더 많은 시간을 제공함)

내 생각에 최적화(실제적으로나 이론적으로)로 작동하지 않는 것이 있습니까? 다른 제안이 있습니까(npm watch와 같은 것이 처리할 수 있는 경우 완벽한 빌드를 보장할 필요가 없습니다. 그것도 괜찮습니다. )? 조언 부탁드려도 될까요? 감사합니다!

요약하자면 사용 사례는 다음과 유사합니다.

1) Godot의 소스 디렉토리에서 npm watch와 같은 filewatcher를 실행하십시오.
2) 사용자가 오래된 파일을 저장/수정
3) scons는 npm에 의해 해당 파일에 대해 즉시 실행됩니다.
4) 컴파일이 성공하면 npm은 scons에게 링커를 실행하고 실행 파일을 연결하도록 지시합니다.

4.1) dep 트리가 캐시된 경우(전체 빌드가 이미 실행된 경우) npm은 링커에 이 시점에서 캐시된 버전의 dep 트리와 연결하도록 지시할 수 있습니다.
4.1) 캐시된 dep 트리가 감지되지 않으면 npm watch는 전체 Godot 빌드를 실행합니다.
4.2) 새 파일 추가와 같이 캐시 무효화가 감지되면 전체 dep 트리 탐색을 수행합니다(npm은 scons와 함께 "캐시된 ​​dep 트리 사용" 옵션을 사용하지 않습니다).

이것이 제 아이디어를 조금 더 이해하기 쉽게 만들었기를 바랍니다. 이 시점에서 무엇이 문제인지 알려주세요 ;D

추신: 이것이 "명백한" 결과와 함께 35개의 null 증분 빌드에서 15초를 줄인 명령이라고 생각합니다... 기본적으로 여기에 설명된 내용을 자동화하고 싶습니다(다소 적거나, + scons에게 정확한 파일을 알려주십시오. 어떤 식으로든 도움이 되거나 도움이 될 수 있는 경우 수정됨):

https://www.scons.org/doc/latest/HTML/scons-user/ch06s04.html

그래서 여기에 몇 가지가 있습니다(특별한 순서는 없지만 yolo 때문에 숫자를 사용하고 있습니다.

1) 증분 null 빌드는 기본적으로 닌자 파일을 생성하는 도구에서 아무 것도 아닙니다. Chrome에는 AFAIK가 2초 미만의 null 증분 빌드가 있습니다. npm watch 아래에서 15초로 35초가 떨어지는 것은 meson 또는 cmake 기반 Ninja 빌드에 비해 여전히 매우 크기 때문에 이것은 중요합니다. Ninja는 명령줄이 변경되는 경우에도 다시 빌드를 수행한다는 점에서 Scons와 동일한 작업을 수행합니다(make는 물론 수행하지 않음).

2) CMake는 최근 CONFIGURE_DEPENDS 를 glob 시스템에 대한 인수로 사용하는 기능을 구현했습니다. xcodebuild 및 msbuild와 같은 도구는 역사적으로(그리고 현재) 디렉터리 변경 감지를 지원하지 않았기 때문에 항상 반대하는 것이 좋습니다. 이것은 Scons가 개선할 수 있는 한 가지입니다. 그러나 나는 이것을 구현하기 위해 프로젝트에 깊이 들어갈 시간도 인내심이 없습니다. 기본적으로 모든 OS는 추가된 파일, 수정된 파일, 제거된 파일 등 내용이 변경될 때 디렉토리를 업데이트합니다. 증분 변경을 수행할 때 변경된 디렉토리를 간단히 확인하고 재구성 검사에서 변경된 디렉토리만 볼 수 있습니다. 이것은 전체 트리가 아니라 더 작은 비트를 globbing하므로 수행되는 작업을 줄일 수 있습니다. 소규모 프로젝트의 경우 괜찮습니다. 이것이 Godot에 도움이 되는지 여부는 약간의 테스트가 필요하며 도움이 되는지 확인하는 데 많은 작업이 필요합니다.

3) Scons가 더 많은 관심을 받고 있는 것은 좋은 일이지만, 개인적으로는 Godot가 더 많이 사용되는 빌드 시스템으로 이동하는 것이 커뮤니티 전체에 더 낫다고 생각합니다. 나는 Scons를 사용하는 어떤 대규모 프로젝트도 Godot 밖에서 생각할 수 없습니다. GNOME/GTK는 최근 meson으로 이동했으며(CMake 건너뛰기) KDE는 꽤 오랫동안 CMake에 있었습니다. 일화적인 증거(따라서 기본적인 확증 편향)이지만 나는 Godot를 사용하고 싶지만 다시는 scons를 만질 필요가 없는 C++ 개발자를 몇 명 알고 있습니다. 불쾌한 경험을 제거하여 개발자의 입에 남은 신맛을 제거하는 것은 어렵습니다. 솔직히 Scons가 최고의 프로젝트가 되길 바랍니다. 그러나 C++ 커뮤니티는 이미 긴 컴파일 시간을 싫어한다는 것을 알고 있습니다. 긴 증분 null 빌드(또는 1개 파일의 긴 증분 빌드)는 현대 세계에서 악몽입니다.

다시 시도할 예정이지만 이를 위해 CMake를 대상으로 할 수 있습니다. CMake에서 meson으로 이동하는 것은 많은 작업을 수행할 수 있는 변환 스크립트가 있는 meson 덕분에 훨씬 쉽습니다. CMake는 새로운 FetchContent 모듈을 사용하여 종속성을 좀 더 쉽게 처리할 수 있습니다. 우리는 그것이 어떻게 작동하는지 볼 것입니다. 나는 이 codegen 스크립트가 별도의 파일로 옮겨져서 기쁩니다. 다른 C++ 표준으로 이동하는 것이 target_compile_features(<target> (PUBLIC|PRIVATE|INTERFACE) cxx_std_<number>) 만큼 간단하기 때문에 CMake를 사용하는 것이 좋습니다.

분명히 모든 빌드 시스템 관련 항목은 논쟁의 여지가 있지만 시도는 해를 끼칠 수 없습니다.

솔직히 말해서 (그리고 이것은 냉담하게 들릴 수도 있습니다) 저는 Scons 프로젝트를 개선하기 위해 깊이 파고들고 싶지 않습니다. 아마도 Python 2.7이 공식적으로 마침내 완전히 종료되고 프로젝트가 Python 3.5 이상으로 나아갈 수 있는 2020년 이후에는 비동기 작업을 통해 조사하거나 개선할 가치가 있을 것입니다. 하지만 그 전까지는 만지지 않는 것이 좋겠습니다.

아마도 Python 2.7이 공식적으로 마침내 죽고 프로젝트가 Python 3.5 이상으로 나아갈 수 있는 2020년 이후에 조사하거나 개선할 가치가 있을 것입니다.

Scons 3는 Python 3.5+를 지원합니다. https://scons.org/tag/releases.html .

나는 Scons를 어떻게 그렇게 싫어하고 CMake라는 구성 엉망을 좋아할 수 있는지 정말로 이해하지 못합니다. 사용자라면 자신의 빌드 설정을 정의하기조차 어렵고 옵션과 유형이 무엇인지 이해하기 어렵습니다. 내적인 정의인데, 나에게 고통만 가져다주었고, Godot가 그것을 사용하지 않았다는 사실에 나는 실제로 안도했다.

어쨌든 더 나은 솔루션이 될 것 같으면 계속 시도하고 CMake에 대한 내 견해를 바꿀 수 있습니다.

사용자라면 자신만의 빌드 설정을 정의하기조차 힘든 곳,

그것이 묻는다면 CMake가 잘못 사용되고 있는 것입니다. 모든 도구 체인 설정은 도구 체인 파일에 있어야 하며 모든 프로젝트 특정 구성은 플래그(또는 GUI 또는 캐시 파일 편집 등)를 통해 전달됩니다. 모든 것이 문서화되고 입력되며 프로젝트 작성자도 노출된 구성을 잘 문서화하고 입력할 수 있습니다. CGold와 최신 CMake 표준을 읽어야 합니다.

@Faless 아무도 CMake 언어가 끔찍

@OvermindDL1 은 CGold를 읽으라는 제안을 좋아합니다.

그것이 묻는다면 CMake가 잘못 사용되고 있는 것입니다.

글쎄, 나는 그것을 잘못하고있는 곳에서 내가 만난 모든 프로그램을 추측합니다.

솔직히 말해서, 나는 -DI_LOVE_CMAKE_AND_MAKE_DEFINES_LONG=on (정말? on ?)를 통해 플래그를 변경하는 것을 싫어합니다. 캐시 파일 O_o 편집에 대한 아이디어는 말할 것도 없습니다. 또는 플래그를 변경하려면 기본적으로 빌드 폴더를 삭제하고 처음부터 다시 시작해야 합니다(캐시가 다르기 때문에)... 증분 빌드의 경우...

편집: 또한 내가 Scons에 대해 정말 좋아했던 것(적어도 Godot에서는, 물론 이것은 다른 빌드 시스템에서도 가능할 수 있음)은 실제로 표준이나 문서를 읽지 않고 scons -h 실행한다는 것입니다

GitHub에서 본 빌드 파일의 95%가 잘못되었습니다. 사람들은 빌드 시스템에 게으르며 화물 숭배 관행을 따라 무언가를 엮습니다.

@isaachier , 메트릭처럼 나쁜 CMake 파일과 좋은 CMake 파일의 두 가지 예를 제공할 수 있습니까? https://github.com/ARMmbed/mbedtls/blob/development/CMakeLists.txt ?

내가 본 것보다 낫습니다. 그래도 CMake >= 3.0을 사용하지 않는다면 최신 CMake에 대한 경험이 아닙니다.

글쎄, 나는 그것을 잘못하고있는 곳에서 내가 만난 모든 프로그램을 추측합니다.

요즘은 잘 하는 것 같아요.

솔직히 말해서 -DI_LOVE_CMAKE_AND_MAKE_DEFINES_LONG=on(정말? on?)을 통해 플래그를 변경하는 것을 싫어합니다. 캐시 파일 O_o 편집에 대한 아이디어는 말할 것도 없습니다. 또는 플래그를 변경하려면 기본적으로 빌드 폴더를 삭제하고 처음부터 다시 시작해야 합니다(캐시가 다르기 때문에)... 증분 빌드의 경우...

on 을 사용할 필요는 없으며 true , 1 및 기타 다양한 것을 사용할 수 있습니다. 플래그 이름과 잘 어울리는 적절한 불리언 이름을 선택할 수 있도록 하기 위함입니다.

그리고 옵션을 변경하면 빌드 폴더를 다시 빌드할 필요가 없습니다. cmake는 필요할 때 다시 빌드하는 데 탁월합니다.

그래도 C/C++ 빌드 시스템을 만지는 모든 사람은 CGold 와 CMake의 공식 매뉴얼을 읽어야 합니다. 그것은 종종뿐만 아니라 많은 짧은, CMake의 권리를 사용하는 정말 쉽습니다. 고대 CMake2 방법론을 사용해서는 안 됩니다. 실제로 CMake 2.x 버전에 의존하는 사람은 절대적으로 잘못된 일을 하고 있습니다(대상 및 도구 모음을 제대로 사용하지 않거나 옵션을 제대로 설정하지 않는 등...).

설명에 감사드립니다. 저는 여전히 회의적이지만 Godot에서 어떻게 작동할지 기대하고 있습니다. :).

@slurps-mad-rips C++11 모드를 활성화하기 위한 CMake 예제 코드가 포함된 귀하의 게시물은 다음을 포함하지만 이에 국한되지 않는 다양한 이유로 인해 완전히 비표준 CMake입니다.

• 노출되지 않은 변수를 설정합니다.
• 도구 체인이 아닌 파일에 설정된 도구 체인 인수.
• C++11 모드 활성화와 같은 작업을 수행하는 방법은 절대 아닙니다.
• 무능한.

해당 게시물에 표시된 자체 설명 단순화 중간자 코드를 감안할 때:

cxx = meson.get_compiler('cpp')
# This is an extremely simplified approach. One can do a different option when dealing with MSVC and gcc support.
args = compiler.get_supported_arguments('-std=c++11', '-stdlib=libc++')
add_project_arguments(args)

동등한 단순화(더 많은 속성도 추가할 수 있다는 점에서) CMake는 다음과 같습니다.

set_target_properties(godot PROPERTIES CXX_STANDARD 11)

그리고 그것은 사용된 툴체인이 해당 모드를 설정해야 한다는 것을 알고 있는지 확인합니다(또한 지원하지 않는 컴파일러를 사용하는 경우 실패를 처리하는 방법을 지정할 수 있음). 빌드 파일에 특별한 컴파일러별 명령줄 플래그가 있다고 가정하는 것은 툴체인 파일에만 존재해야 하고 이전 게시물에 표시된 meson 예제가 실제로 특정 인수를 지정한다는 사실은 본질적으로 지원되는 컴파일러를 하드코딩하고 있다는 것을 의미하므로 매우 좋지 않은 형식입니다.

생각할 수 있는 거의 모든 도구 체인(다양한 종류의 MSVC, GCC/Clang, Android, iOS, emscripten 등... 등)에 대해 미리 빌드된 CMake 도구 체인

편집: 그리고 광범위한 지원을 결코 무시하지 마십시오. KDevelop(내가 사용하는 IDE, 흥미롭게도 CMake를 빌드 형식으로 사용하고 직장에서 가끔 CLion을 사용하고 CMake도 사용)을 위한 프로젝트 파일을 생성할 수 있는 meson에 대해 아무 것도 찾을 수 없습니다. Visual Studio!)는 이제 기본적으로 CMake 프로젝트를 열 수 있습니다(원하는 경우 CMake가 대부분의 IDE에 대한 프로젝트를 직접 생성할 수 있는 것 외에도)

@OvermindDL1

절대적으로 비표준 CMake가 아닙니다. 코드 샘플은 CXX_STANDARD 가 존재하지 않는 버전인 CMake 3.0을 대상으로 합니다. 여기 에서 cxx_std_ 및 표준 번호와 함께 target_compile_features 를 사용하는 것을 쉽게 알 수 있습니다. 이것은 표준 버전을 설정하는 새롭고 현대적인 cmake 방법입니다. set_target_properties 는 이전의 대상별 접근 방식입니다.
사실, CMake의 문서 에서 가져온 정확한 코드는

target_compile_features(mylib PUBLIC cxx_std_11)

그러나 CXX_STANDARD 는 clang이 구성되지 않는 한 기본적으로 libstdc++를 사용하기 때문에 clang에 대한 libc++ 지원을 설정 -stdlib=libc++ 지원하는지 확인하고 제너레이터 표현식을 통해 컴파일러에 전달하는 것입니다. 이와 관련하여 노출되지 않은 변수와 관련된 것은 없습니다.

또한 다음 시도에서 Meson보다 CMake를 대상으로 할 것이라는 점을 감안할 때 몇 달 전에 작성한 댓글에서 수정하기 위해 댓글을 삭제한 것에 대해 감사하지 않습니다. 재치가 부족하고 내 의견으로는 대화에 아무 것도 추가하지 않습니다.

CMake 3.0은 더 이상 지원되지 않을 만큼 오래되었습니다(2014년 6월 10일). 현재로서는 CMake 3.12보다 최신 버전을 유지하는 것이 좋지만 현재로서는 CMake 3.10보다 낮은 버전을 실행해서는 안 됩니다.

그리고 예, 당신이 준 예는 전적으로 반대하는 것이 좋습니다 (CGold조차도 그렇게하지 않는다고 언급한다고 생각합니다).

그리고 예, 저는 target_compile_features를 의미했습니다. ^.^;

그러나 CXX_STANDARD는 clang이 구성되지 않는 한 기본적으로 libstdc++를 사용하기 때문에 clang에 대한 libc++ 지원을 설정하지 않습니다(그리고 대부분의 Linux 배포판에서 기본적으로 libc++를 사용하도록 구성되지 않습니다. 이는 링커 오류 및 ABI 문제를 일으킬 수 있기 때문입니다). 이때 유일한 방법은 컴파일러가 -stdlib=libc++를 지원하는지 확인하고 생성기 표현식을 통해 컴파일러에 전달하는 것입니다. 이와 관련하여 노출되지 않은 변수와 관련된 것은 없습니다.

현재 툴체인은 모두 clang에 대해 잘 수행합니다. 적어도 C++14에서는 (그리고 몇 개의 C++17과 함께) 컴파일합니다.

또한 다음 시도에서 Meson보다 CMake를 대상으로 할 것이라는 점을 감안할 때 몇 달 전에 작성한 댓글에서 수정하기 위해 댓글을 삭제한 것에 대해 감사하지 않습니다. 재치가 부족하고 내 의견으로는 대화에 아무 것도 추가하지 않습니다.

죄송합니다. 백로그를 읽는 동안 날짜를 확인하지 못했습니다(여기에 많은 백로그가 있습니다). 나는 방금 몇 년 동안 보아온 어떤 종류의 현대적인 제안에 대해 비참하게 잘못된 것으로 보이는 것을 발견했고 얼마 지나지 않아 게시물에 수정 사항이 표시되지 않아 잘못된 정보가 전파되지 않기를 원했습니다. :-)

이때 할 수 있는 유일한 방법은 컴파일러가 -stdlib=libc++를 지원하는지 확인하고 생성기 표현식을 통해 컴파일러에 전달하는 것입니다.

그러나 네, 절대적으로 지금까지 이제까지 빌드 파일에 나타나지 않아야합니다 툴체인 파일의 작업입니다.

이와 관련하여 노출되지 않은 변수와 관련된 것은 없습니다.

나는 단지 단일 위치의 다른 곳에서 사용된 다음 설정한 변수를 참조했을 뿐입니다. 이는 다양한 이유로 CGold에서 권장되지 않습니다.

CMake 3.0은 더 이상 지원되지 않을 만큼 오래되었습니다(2014년 6월 10일). 현재로서는 CMake 3.12보다 최신 버전을 유지하는 것이 좋지만 현재로서는 CMake 3.10보다 낮은 버전을 실행해서는 안 됩니다.

그들은 해서는 안 되지만 일부 장소는 있습니다. 최신 기술과 최신 기술을 유지하려는 게임 엔진의 경우 최신 CMake를 유지하는 것이 좋습니다. 그러나 나는 3.5와 어떤 경우에는 3.4와 같은 이전 버전에서 멈춘 매우 활동적인 프로젝트에 대해 잘 알고 있습니다. 사실, 잘 알려진 일부 C 라이브러리는 여전히 CMake 2.8을 대상으로 합니다(SDL2, libssh2, libgit2 등 참조).

그러나 예, 그것은 도구 체인 파일의 작업이며 절대 빌드 파일에 나타나지 않아야 합니다.

툴체인 파일이 잘 작성되었고 가능한 모든 시스템과 모든 버전의 CMake를 포함한다는 가정을 하는 것은 현재의 일반적인 C++ 생태계에 문제를 야기합니다. 그 소리를 사용하는 경우, 된 libstdc ++ 또는 libc의 ++ 용으로 컴파일 할 수있는 옵션은 (특히 통해 사용하는 경우 FetchContent 호출) 라이브러리에 의해 제공 될 필요가있다. CheckIncludeCXX 및 CheckCXXCompileFlag 아직 존재하지 않는 GCC 아래에 있지만 (반대 및 부사장) 연타 아래에있는을 심지어 일부 플래그 필요합니다. 여기서 주요 문제는 컴파일러 인터페이스가 크게 갈라지고 공급업체가 호환성 옵션을 용이하게 하거나 심지어 공통 인터페이스에 대해 논의하는 데 시간을 소비하는 대신 우리가 코드를 작성하기만 하면 개발자인 우리에게 그 동작을 강요한다는 것입니다. 신뢰 나,이 행성에 아무도 더 나보다 C 및 C ++ 빌드 시스템과 의존성 관리의 상태에 대한 화가,하지만 필요 CMake에 라이브러리를 기존의 실용 없습니다. 빌드 시스템에서 CMake로 전환할 때 좋은 점은 가장 최신의 기능으로 게이트를 시작할 수 있다는 것입니다. 문제는 빌드 시스템의 정체가 됩니다. 아무도 만지기를 원하지 않기 때문입니다(코드 생성 빌드 스크립트를 별도의 스크립트로 분리한 용감한 영혼 제외). 그러나 손에서 벗어나지 않도록 몇 가지 작업이 필요할 것입니다. (그 이유는 ... 내 말은 그것이 빌드 시스템이기 때문입니다. 항상 그렇습니다)

특히 CMake에서 빌드 스크립트를 작성하는 것을 실제로 즐기는 사람은 나일 것입니다.).

툴체인 파일이 잘 작성되었고 가능한 모든 시스템과 모든 버전의 CMake를 포함한다는 가정을 하는 것은 현재의 일반적인 C++ 생태계에 문제를 야기합니다. clang을 사용할 때 libstdc++ 또는 libc++용으로 컴파일하는 옵션(특히 FetchContent 호출을 통해 사용되는 경우)은 라이브러리에서 제공해야 합니다.

그런 것들은 도구 체인이 작동할 수 있는 도구 체인에 속성이 전달되어야 합니다.

뿐만 아니라 매우 독특한 설정이 있는 경우 매우 맞춤화된 Android 빌드와 같은 도구 체인 파일을 포함하는 것이 완전히 합리적입니다(cmake 도구 체인의 확장된 폴리 세트가 지금까지 필요한 거의 모든 것을 다루었지만).

문제는 빌드 시스템의 정체가 됩니다. 아무도 만지기를 원하지 않기 때문입니다(코드 생성 빌드 스크립트를 별도의 스크립트로 분리한 용감한 영혼 제외). 그러나 손에서 벗어나지 않도록 몇 가지 작업이 필요할 것입니다. (그 이유는 ... 내 말은 그것이 빌드 시스템이기 때문입니다. 항상 그렇습니다)

이것은 실제로 지금 CMake를 선택하기 위한 좋은 포인트입니다. 좋든 나쁘든 10년 이상의 이전 경험을 처리한 후 현재 잘 작동하는 잘 정의된 표준 세트가 있습니다.

특히 CMake에서 빌드 스크립트를 작성하는 것을 실제로 즐기는 사람은 나일 것입니다.).

나는 그것이 나에게 의미가 있을 만큼 충분히 길게 썼지만 그것이 모든 사람에게 반드시 해당된다는 것을 의미하지는 않지만 대안과 비교하여 확실히 그것을 즐깁니다. ^.^;

저는 지난 몇 년 동안 다양한 빌드 시스템을 사용해 왔습니다. 최근에 나에게 가장 의미가 있었던 것은 CMake이지만 SCons의 매력과 그것이 얼마나 유연한지 확실히 알 수 있습니다.

SCon이 완벽하지 않더라도(빌드 시스템이 무엇입니까?) 충분히 좋을 수 있습니다.

• 필요한 기능을 제공합니까?
• 얼마나 많은 오버헤드를 생성합니까?

SCons가 두 포인트 모두에 대해 "충분히 좋은" 점수를 받으면 그대로 유지하십시오.

SCons를 다른 것으로 교체하자고 제안한 사람 중에 실제로 Godot 빌드 시스템이 어떻게 작동하는지 배우기 위해 노력한 사람이 있습니까?

힌트로, 그것은 엄청나게 복잡하고 많은 양의 플랫폼에 대해 CMake 빌드를 사용하고 우리가 하는 방식으로 동시에 여러 빌드 대상을 구성/컴파일할 수 있도록 하는 많은(또는 어떤) 프로젝트도 없다고 생각합니다.

"저는 Godot 빌드 시스템을 다른 곳으로 이식할 것입니다"라고 말한 사람들의 모든 노력은 SCons가 처리하는 것의 복잡성을 깨닫고 지금까지 비참하게 실패했습니다.

나에게 그것은 지금까지 작업에 가장 적합한 도구입니다. 아무것도 가까이에 없습니다. 여러분이 기본 컴파일 시간(SSD가 있는 중급에서 고급 시스템에서 단 4/5초)에 대해 불평한다면, 먼저 Godot가 빌드할 때 수행하는 모든 것을 이해하고 CMake 또는 다른 모든 것에서 수행하는 방식을 확인해야 합니다. .

나는 살펴 보았다. CMake 또는 다른 곳에서 실행 취소할 수 없다고 확신하지 않습니다. 그러나 나는 또한 게으르다 ;). 우리는 무슨 일이 일어나는지 볼 것입니다.

바젤 포트를 한 사람으로서. 나는 Godot 편집기가 아이콘 없이 시작되는 지점에 도달할 수 있었습니다.

CMake가 그 지점에 도달할 수 있다고 확신합니다.

추신. 플랫폼이 많은 가장 가까운 경쟁자 프로젝트는 Urho3d입니다.

cmake에서 내 bazel 결과를 재현했습니다.

https://github.com/fire/godot/tree/cmake

Visual Studio 2017이 설치되어 있다고 가정합니다.

git clone https://github.com/fire/godot.git -b cmake
scons p=windows
Modify platform/register_platform_apis.gen.cpp
#include "register_platform_apis.h"

void register_platform_apis() {
}

void unregister_platform_apis() {
}

cmake 설치

choco install cmake ninja -y
# Open visual studio command prompt amd 64 2017 native
# Go to godot source directory
cd ..
mkdir build
cd build
cmake ../godot -GNinja
ninja

가지고 놀아주세요. 편집기에는 bazel 빌드(아이콘 없음)와 동일한 문제가 있지만 이 샘플이 도움이 될 수 있습니다.

메모

• 아이콘은 71175b45f819e7cc5e4368dbf3e42abdd19af542부터 작동합니다.
• 비주얼 스크립트와 GDscript 작업

@fire 감사합니다. 이러한 CMake 파일의 유지 관리를 더 쉽게(그리고 새로운 기능이나 컴파일러 플래그를 추가하는 데 소요되는 시간) 개선해야 할 부분이 많이 있습니다. 다음 주말에 처리할 수 있지만 일정이 보류 중입니다.

멋진 작품 @fire. 여기 누군가가 하나 이상의 빌드 시스템에서 무언가를 생성할 수 있다는 것을 알게 되어 기쁩니다 . 즉,

약간의 업데이트. 나는 오늘 @fire 의 작업을 지원 하므로 문자열을 처리하고 목록에 추가한 다음 더 많은 문자열을 처리하고 목록에 추가하는 등의 작업을 수행하는 대신 삶을 좀 더 쉽게 만들 수 있습니다.

이상적으로는 코드 생성 스크립트가 빌드에 대한 지식 없이 실행 가능한 것처럼 실행될 수 있어야 합니다. 적절한 파일이 전달되는 한 다른 빌드 시스템으로 완전히 이식하는 것이 좋습니다.

@slurps-mad-rips SCons 시스템에서 추출하는 것은 SCons에서도 좋은 생각입니다. 처리 중인 논리가 너무 많아 GIL을 중단하고 빌드 성능을 저하시킬 수 있습니다. 때때로 병렬로 빌드할 때 일부 파일 닫기/열기 경쟁 조건으로 이어집니다(종종 컨텍스트에서 로 파일을 열어 해결됨).

모두들 안녕,

이 공간을 사용하여 사람들이 CMake에 대한 포트에서 최신 정보를 얻을 수 있도록 할 것입니다. 요청이 있는 경우 별도의 문제를 만들고 변경 사항을 추적할 것입니다. 하지만 이 영역은 토론의 백로그가 많고 컨텍스트를 너무 많이 잃는 것은 낭비라고 생각합니다.

나는 탈선한다. 나는 컨퍼런스에 참석하는 동안 다음 주 동안 CMake 포트에서 휴식을 취해야 하지만 여기 에서 나의 초기 이식 시도의 노력을 볼 수 CONFIGURE_DEPENDS 파일을 Ninja와 섞는 것은 실제로 꽤 좋습니다.

마지막으로 다른 CMake 프로젝트를 작성하는 경우 이러한 모듈이 유용할 수 있기 때문에 제가 작성한 도우미 CMake 모듈을 최대한 활용하는 것이 좋습니다.

최신 3.1 알파로 업데이트할 수 있었습니까? 알파는 좋은 표적이 될 수 있습니다. 현재 빌드를 시도 중입니다.

이 문제의 제목은 빌드 시스템을 Meson으로 옮기는 것을 고려하십시오 . 여기서 CMake 토론을 하는 것은 부적절하다고 생각합니다. CMake에 대한 토론에는 자체 문제가 있어야 합니다. Meson과 다른 것의 비교는 괜찮습니다.

@zaniar 일반적으로 빌드 시스템과 관련하여 이 스레드에서 많은 논의가 있었습니다. 제목이 업데이트되지 않았다고 해서 갑자기 새로운 문제를 만들고 토론을 위한 모든 맥락을 잃고 처음부터 다시 시작한다는 의미는 아닙니다. 몇 개월 치의 토론을 갑자기 버리라고 하는 것은 부적절하다고 생각합니다.

@fire 지난 몇 주 동안 일로 바빴고 금요일에 마감일이 컸고 그 이후에는 포크를 최신 정보로 업데이트할 시간이 생겼습니다. 로컬에 몇 가지 변경 사항이 있어 푸시하는 것을 잊었지만 지금은 시간이 없습니다. (이 빌드 시스템 포트, 내 gnu m4 포크, 이달의 마지막 주에 C++ 표준 샌디에고 회의 및 CppCon 을 위해 작성 중인 15개 제안서 사이에 나는 완전히 늪에

예, Meson이 원래 토론 대상이었지만 그 이후로 다른 빌드 시스템이 거론되고 논의된 것이 자연스러운 일이라고 생각합니다. @slurps와 같이 퍼뜨리는 대신 이 문제 내에서 토론을 유지하는 것이 합리적일 것입니다. -mad-rips가 말했다.

CMake로 이동하는 데 동의합니다. 툴체인으로 많은 지원을 받고 있습니다. 예를 들어 Android 빌드는 Godot가 '유지할 수 없는' 것처럼 보이는 SCsub 파일에서 수행하는 작업에 비해 매우 쉬워집니다.

오픈 소스 프로젝트로서 Godot는 유지하기 쉽고 기여자들이 더 잘 알고 기여할 수 있는 솔루션을 사용해야 합니다.

또한 이것이 GDNative 채택에 중요하다고 생각합니다. 어떤 빌드 도구를 사용하든 iOS, Android 등 모든 플랫폼에 대한 빌드를 지원하는 쉽게 수정할 수 있는 빌드 스크립트가 있는 예제 또는 표준 프로젝트가 있어야 합니다.

또한 일반 모듈은 공유 라이브러리로 컴파일할 수 있어야 합니다. 이것은 엔진을 다운로드 가능한 여러 구성 요소로 분리할 수 있도록 #19486과 관련이 있습니다.

나는 실제로 이것들을 다루고 있다. 곧 있을 C++ 표준 회의인 CppCon으로 바쁘고 직장에서 다음 주에 릴리스를 할 예정이기 때문에 한동안 변경 사항을 미루지 않았습니다. 포트를 완료할 시간이 많지 않았지만 앞으로 C++ 코드를 생성하는 python 스크립트를 추출하는 데 대부분의 시간을 할애할 것입니다. 이번 주말에 항구에서 작업을 재개하기를 희망합니다. 현재 자동으로 타사 종속성을 획득하고 리포지토리에 저장된 패치를 적용할지 여부를 평가하고 있습니다. 나는 핵심 개발자를위한해야합니까 질문 하나가 조직의 기본 REPO에서 자신의 저장소에있는 모든 THIRD_PARTY REPOS을 깨는 것이 얼마나 열려 있습니다. 나는 내 프로젝트에서 FetchContent 에 상당히 의존하고 있으며 현재 약간 분기된 이러한 타사 종속성에 대해 그렇게 할 수 있기를 바랍니다. 이렇게 하면 각 타사 라이브러리가 이식되면 코어 저장소에 증분 변경을 수행하는 동시에 cmake 파일을 정리하기 위해 차례로 각 작업을 수행할 수 있습니다.

또한 엔진 자체도 모듈화하려고 노력하고 있으므로 누군가가 원할 경우 이러한 구성 요소 가 기술적으로 서로 별도로 업데이트될 @chanon이 언급한 문제를

마지막으로 핵심 개발자가 시스템에서 발견되는 경우 이를 위한 몇 가지 추가 빌드 도구에 대한 지원을 추가하고 있습니다. clang-format, clang-tidy, ccache 또는 sccache, distcc, clang-check, 주소 새니타이저, ubsanitizer, 스레드 새니타이저 등과 같은 것 감지하고 있음)을 선택적으로 활성화할 수 있습니다. 최소한 sccache 또는 ccache를 사용하면 빌드 간에 전환할 때 또는 그 반대로 전환할 때 약간의 빌드 개선이 제공됩니다. CMake 3.13이 출시되기를 기다리는 것은 내가 의존해야 했던 몇 가지 번거로운 작업을 해결할 수 있기 때문에 좋을 것이지만 중요한 것은 현재 "시작하기" 워크플로가 다음과 같이 되도록 설정한다는 것입니다. Python 3.5 이상을 통해 pip install 를 계속 실행하려면 virtualenv 내부에 있으므로 사람들이 시스템 환경을 엉망으로 만들 필요가 없습니다. (이렇게 하면 다른 사람들이 다양한 코드 생성 스크립트에 대한 종속성으로 추가 python 라이브러리를 사용하여 실험할 수 있으며 나중에 제거하는 것을 기억할 필요가 없습니다)

아무튼 갑작스러운 업데이트 소식에 죄송합니다. 나는 이 항구를 완성하는 데 전념하고 있지만 최근에 삶이 방해가 되었습니다 😅

나는 내 프로젝트에서 FetchContent에 상당히 의존하고 있으며 현재 약간 분기된 이러한 타사 종속성에 대해 그렇게 할 수 있기를 바랍니다.

또한 Hunter 를 사용하여 Godot 특정 코드 저장소(예를 들어 github와 같은 특별한 git repo)를 만들고 건물, 캐시 등을 필요에 따라 적절하게 처리할 때 모든 종속성에 액세스할 수 있습니다. (또는 모든 종속성을 '메인' Hunter 패키지 저장소에 제출하고 그대로 사용하십시오). Hunter는 단일 cmake 파일(HunterGate.cmake)이며 패키지 저장소 정보(공식 파일이든 사용자 정의 파일이든)를 얻기 위해 이 파일을 호출합니다.

겸손한 요청: 이 문제의 댓글 스레드가 엄청나게 커졌습니다. 이 문제를

여러분, 안녕하세요. 저는 작은 게임을 만들기 위한 다음 엔진으로 Godot를 사용할 계획입니다.

나는 이 대화를 보았고 CMake와 Meson(그리고 autotools, tup, plain make, waf, SCons, 이 모든 도구에서 전체 프로젝트 시도...)에 경험이 있는 사람으로서 피드백을 제공하고 싶었습니다.

내가 더 집중적으로 사용한 시스템은 Autotools, CMake 및 Meson이었습니다. 이미 프로덕션 설정에서 다른 모든 빌드 시스템을 폐기했기 때문에 지난 몇 년 동안 Meson과 CMake를 사용해 왔습니다.

cmake의 장점

• Visual Studio(Meson이 요즘에는 잘 지원하지만 최근에는 시도하지 않았다고 생각합니다) 및 특히 XCode(여기서 더 부족하다고 확신합니다)에 관심이 있다면 성숙한 프로젝트 생성기.
• 폭넓은 채택, IDE에서 더 많은 지원
• 폭넓은 채택 -> 기여를 얻기가 더 쉽습니다(Meson은 배우기 쉽지만 말해야 함)

메손의 장점

• 기본적으로 많은 유용한 대상: 새니타이저, Unity 빌드 무료, 미리 컴파일된 헤더 무료, 적용 범위 무료...
• 문서는 CMake 문서에서 엉덩이를 걷어차: http://mesonbuild.com/
• 크로스 컴파일이 훨씬 쉽다는 것을 알았습니다.
• Meson은 각각의 일을 하는 분명한 방법을 가지고 있습니다.

어느 것을 선택할까요? 교차 컴파일이 집중적이고 빠른 컴파일 시간에 관심이 있는 경우 Meson을 선택합니다(기본적으로 Unity 빌드 및 미리 컴파일된 헤더가 지원됨).
CMake가 표준이고 기여가 팀에 중요할 수 있기 때문에 저는 CMake를 고려할 것입니다. 나는 Meson을 개인적으로 선택할 것이지만 그것은 단지 개인적인 의견일 뿐입니다. 왜냐하면 도구가 훨씬 더 좋고 시간을 절약할 수 있기 때문입니다(CMake 스크립팅, 공간 처리, 생성기 표현식 등... 당신을 보고 있습니다).

아래에서 이런 뻔뻔한 자기 홍보를 해서 죄송합니다만, 맥락이 그것을 구걸하고 있다고 생각합니다.

궁금한 사람이 있으면 여기에 약간의 기본적인 Meson에 대한 일련의 기사가 있습니다(4개 기사).

• https://medium.com/@germandiagomez/getting -started-with-meson-build-system-and-c-83270f444bee
• https://medium.com/@germandiagomez/getting -started-with-meson-in-c-part-2-58150354ff17
• https://medium.com/@germandiagomez/getting -started-with-meson-in-c-part-3-70b9bc419957
• https://medium.com/@germandiagomez/getting -started-with-meson-part-4-8bceec6149e1

StackOverflow의 빌드 시스템에 대한 (약간 오래된) 응답이 있습니다.

https://stackoverflow.com/questions/5837764/autotools-vs-cmake-for-both-windows-and-linux-compilation/24953691#24953691

그냥 내 2 센트 :)

@germandiago 그것은 훌륭한 글입니다 -- 저는 이 문제를 잠시 동안 추적해 왔으며 슬프게도 CMake 전용인 godot + CLion으로 작업할 수 있다면 훌륭 할 것입니다.

예, 대부분의 최신 IDE는 CMake 전용 및/또는 일부 사용자 정의 빌드 시스템 및/또는 많은 기능을 잃는 '원시 호출'입니다. CMake는 가치가 있든 없든 정말 표준이 되었습니다.

@dorkbox 내가 작업 중인 이러한 변경 사항을 얻을 수 있다면 분명히 CLion(cmake + ninja) 워크플로에서 작업할 수 있을 것입니다.

@germandiago

저는 CppCon 2018을 기준으로 meson의 저자와 이제 실제로 친구가 되었습니다(다소 😛). 우리는 둘 다 "Remember Fortran"이라는 제목의 모듈에 관한 다음 회의에서 같은 논문을 보고 발표할 예정입니다. 그 회의에서 그의 논문(사실은 다음 주입니다!)과 우리는 CppCon에서 같은 빌드 시스템 패널에 있었습니다.

나는 중간자를 사용 싶어요. 스레드에서 더 자세히 읽어보면 중간자 포트를 시도했지만 당시에는 상황이 Scons와 너무 통합되어 있었습니다. 나는 여전히 현재 코드 생성 스크립트를 별도의 '실행 가능한' 스크립트로 꺼내고 있으므로 미래에 Meson으로 이동하는 것이 문제가 되지 않을 것입니다. 그러나 작업 속도가 느리고 scons를 완전히 삭제할 수 있도록 코드 생성을 돕기 위해 몇 가지 jinja 템플릿을 작성했습니다. 즉, 내 공개 포크는 구식이지만 집에 있는 포크는 조금 더 앞서 있습니다(개인 포크와 동기화됨). 불행히도 일이 방해가 되었고 샌디에고는 불행히도 내 시간을 더 많이 '훔칠' 것입니다. 그러나 그 후에는 개인 포크에 있는 일부 로컬 실험을 자유롭게 제거하고 마침내 Godot cmake 기차에 다시 올라야 합니다. 현재 워크플로 프로세스에 큰 지장을 주지 않으면서 전체 풀 리퀘스트가 들어올 수 있도록 최선을 다하고 있습니다.

(제쳐두고 : 인내 주셔서 감사합니다 모두 당신은 했어 동안이에 내가 작업 나는 그것을 시작한 이후 동안이되었습니다 것을 알고,하지만 난 이제 ++은 C의 미국 국립 바디 내 일정을 기준위원회를 고용주를 나타냅니다. 특히 모듈, 코루틴 및 범위와 같은 중요한 주제를 다룰 때 최근에 좀 더 꽉 차 있습니다.)

예, 대부분의 최신 IDE는 CMake 전용 및/또는 일부 사용자 정의 빌드 시스템 및/또는 많은 기능을 잃는 '원시 호출'입니다. CMake는 가치가 있든 없든 정말 표준이 되었습니다.

IDE에서 meson을 사용하기 위한 유용한 도구:

https://github.com/prozum/meson-cmake-wrapper

그것은 IDE가 CMake를 사용하고 있다고 생각하게 하지만 실제로는 내부적으로 중간자를 사용하고 있습니다.

몇 가지 배경: 저는 (10?) 년 동안 CMake의 열렬한 지지자였지만 작년 정도에 meson과 사랑에 빠졌습니다. Meson은 CMake의 성가신 많은 부분을 수정/방지하면서 CMake의 유용한 기능을 가지려는 의도로 작성된 것 같습니다. 내가 현재 프로젝트에서 meson을 채택하는 데 직면하고 있는 한 가지 장애물은 IDE 지원입니다. 방금 위의 도구를 발견했으므로 도움이 될 것입니다.

모든 빌드 시스템에는 주요 결함이 있습니다. 그 이상은 기술적인 관점에서 볼 때 scons, autotools, cmake, meson 또는 make vs ninja 종교가 무엇이든 변경할 이유가 없습니다. 다른 모든 빌드 시스템 변경 버그를 이 버그의 복제로 닫는 것이 좋을 것이라고 생각합니다.

<reduz> iFire: no, you did not, all you did was build it but did not port any of the dozens of custom scripts that generate code
<iFire> reduz: the other person worked on the little python script generation on her branch
<iFire> so they directly imported the python env
<iFire> it's workable
<reduz> iFire: that is what everyone said that attempted it, and failed :P
<reduz> there are too many things in there

reduz가 잘못된 @slurps-mad-rips :).

아직 언급되지 않은 방에 800lb 고릴라. 명성에 대한 Godot의 주장 중 하나는 플랫폼 간 호환성입니다. 마이그레이션할 가능성이 있는 빌드 시스템은 무엇이든지 Godot가 목표로 하는 모든 플랫폼에서 사용 가능하고 테스트되어야 합니다. 그러한 마이그레이션의 배후에 있는 사람은 지원되는 모든 플랫폼에서 마이그레이션을 테스트하거나 최소한 그렇게 하는 팀의 일원이어야 합니다. 그렇지 않으면 나는 Godot 철학과 일반적으로 나쁜 생각에 반대되는 그러한 움직임을 보게 될 것입니다.

@lazybullfrog 데스크탑과 여러 모바일 장치용으로 약 5개의 개별 컴퓨터에 액세스할 수 있습니다. cmake에 대한 내 포트의 일부는 현재 모든 플랫폼에서 사용 가능한 cmake 도구 체인이 있는지 확인하는 것입니다.

@slurps-mad-rips 하이쿠 중 하나인가요? 그렇지 않다면 기꺼이 테스트를 돕겠습니다. 감사 해요.

cmake에 대한 내 포트의 일부는 현재 모든 플랫폼에서 사용 가능한 cmake 도구 체인이 있는지 확인하는 것입니다.

플랫폼용 cmake 도구 모음이 필요한 경우 https://github.com/ruslo/polly에 미리 빌드된 도구 모음이 있을 수 있으며 없는 경우 PR해야 합니다. :-)

@slurps-mad-rips 어떻게 된 건가요? 1월 14일에 코드를 업데이트한 것으로 나타났습니다. Windows에서 컴파일을 시도했지만 pkgconfig를 찾지 못했습니다.

@fire life는 내 방식대로 커브볼 몇 개를 던지기로 결정했고 내가 처리해야 했습니다. 불행히도 개인적인 물건. 나는 작업에 집중하고 Godot에 복사되는 작업의 양을 줄이기 위해 사용하고 있는 IXM 라이브러리를 마무리했습니다. 운 좋게도 저는 일주일 후에 휴가를 가므로(이번 주말에 열리는 WG21 ISO 회의를 위해 Kona로 향합니다) 이에 대해 작업할 여가 시간이 있고 (잘하면!) macOS, Linux 및 Windows 곧™용으로 작동하는 빌드입니다. Android와 iOS, FreeBSD와 Haiku(미안합니다 @lazybullfrog , 일찍/자주 테스트하는 것을 환영하지만)는 그 다음으로 저의 다음 우선 순위가 될 것입니다.

지금까지 작업/차단기의 가장 큰 덩어리는 Python 스크립트를 Scons와 분리되고 프로세스처럼 실행되는 "설치 가능한" 도구로 추출하는 것입니다. 의존성, 설정 등의 실제 파악은 비교하기 더 쉬웠습니다.

@slurps-mad-rips, 인생은 나에게도 몇 개의 커브 볼을 던졌습니다. 아마도 우리는 야구 팀을 시작해야 할 것입니다. 😂

다행스럽게도 내가 마지막으로 언급한 이후로 그 커브 볼 중 하나는 Haiku 및 FreeBSD가 설치된 32GB 램이 있는 8코어 Xeon이었습니다. 아마도 곧 두 가지 모두를 테스트하는 데 도움이 될 시간을 갖게 될 것입니다.

이 두 플랫폼이 모두 주목을 받고 있다는 사실이 정말 기쁩니다. 곧 테스트를 기대하십시오.

여러 빌드 시스템을 갖는 것이 합리적이라고 생각합니다. 아마도 잘 지원되는 공식 빌드 시스템과 "알아낸" 기반으로 제공되는 다른 시스템일 것입니다. 사용자는 관계없이 자신의 빌드 시스템을 사용하기를 원할 것이므로 작업을 한 곳으로 풀링하지 않는 이유는 무엇입니까?

상황이 그렇게 되면 Bazel 포트에 기꺼이 기여할 것입니다.

여러 빌드 시스템을 갖는 것이 합리적이라고 생각합니다. 아마도 잘 지원되는 공식 빌드 시스템과 "알아낸" 기반으로 제공되는 다른 시스템일 것입니다. 사용자는 관계없이 자신의 빌드 시스템을 사용하기를 원할 것이므로 작업을 한 곳으로 풀링하지 않는 이유는 무엇입니까?

Linux 패키저로서 저는 다양한 빌드 시스템을 사용하는 수백 개의 프로젝트를 보았습니다. 여러 빌드 시스템을 사용할 수 있는 몇 가지를 보았습니다. 나는 완전히 엉망이 아닌 곳을 본 적이 없습니다. 특히 대체 빌드 시스템이 처음으로 "CMake를 추가하십시오. 정말 멋진" 기여자가 기여한 후 프로젝트에서 사라졌고 유지 관리자가 업데이트를 귀찮게하지 않았을 때.

이 여러 buildsystems 지원에 전혀 가치가 없다, 나는 그 방향으로 가고있는 PR을 병합하지 않습니다. 저는 빌드 시스템의 주요 메인테이너 중 한 명이며, 무언가를 변경해야 할 때마다 대안을 유지해야 하는 부담을 지고 싶지 않습니다.

우리는 현재 모두에게 작동하고 잘 지원되며 변경할 의도가 없는 빌드 시스템을 가지고 있습니다. 누군가 다른 옵션을 정말로 조사하기를 원하고, 최종 결과가 모든 사람에게 효과가 있고, 잘 지원되고 큰 단점 없이 부가가치를 제공할 수 있다면, 우리는 그것을 고려할 것입니다.

누군가 _정말__ 다른 옵션을 조사하기를 원하고, 최종 결과가 모든 사람에게 효과가 있고, 잘 지원되고 큰 단점 없이 부가가치를 제공할 수 있다면, 우리는 그것을 고려할 것입니다.

그것이 내가 CMake 포트로 해온 일입니다. 현재 scons에서 no-op 또는 단일 파일 변경은 현재 컴퓨터(64GB RAM, 유사한 프로세서 등이 있음)에서 10초 이상 걸립니다. ninja + cmake를 사용하면 전체 구성 + 생성 프로세스가 더 적은 시간이 소요되고 빌드는 무작동 빌드에서 0.2초 이내에 완료됩니다(프로세스 시작에 비용이 많이 드는 Windows에서). 또한 mozilla의 sccache 도구가 설치된 경우 사용할 수 있으며, 이는 codegen 부분을 편집하거나 처음부터 재생성된 빌드를 실행하여 내 로컬 환경에 의존하는 것이 없는지 확인하는 데 매우 유용했습니다.

대부분의 시간은 코드 생성 스크립트를 자체적으로 실행할 수 있는 python 스크립트로 추출하는 데 사용되었습니다. 그것이 Godot에 병합된 유일한 것이라면, 이것에 소비한 시간이 완전히 낭비되지 않았을 것입니다. 또한 병렬 처리가 있는 창의 문제를 해결하기 위해 현재 존재하는 run_in_subprocess 해킹을 해결합니다.

방금 여행에서 돌아와서 약간의 작업을 완료할 수 있었습니다. 지금 당장은 수동 scons 실행에서 몇 개의 파일을 복사해야 하지만 시간이 지남에 따라 생성된 소스를 조금씩 잘라내고 있습니다. license.gen.h 및 method_bind.inc 헤더가 현재 가장 큰 목표이지만 시차로 인한 피로와 작업을 처리하기 위해 며칠이 소요됩니다.

(또한 그는 이 진행 상황에 잠시 관심이 있었기 때문에

내 경험에 따르면 Meson은 Windows에서 Android를 빌드할 때 완전히 엉망이 되어 그것을 사용하는 타사 라이브러리(libepoxy) 중 하나를 컴파일할 수 없습니다. 그리고 나는 그것이 구체적인 컴파일러에 너무 많이 묶여 있다고 생각합니다.

내가 원하는 것은 빌드 명령과 별도로 프로젝트 파일과 데이터베이스 파일을 생성할 수 있는 빌드 시스템입니다.

파일에 대한 주요 변경 사항이 있는 새 분기를 체크아웃할 때마다 명령줄에서 Scons를 실행하여 vsproj 파일을 재생성해야 하므로 어쨌든 전체 빌드가 발생합니다. 내가 본 Scons에는 어떤 종류의 프로젝트 생성 단계도 없습니다. 이것이 또한 clang-tools에서 사용하기 위해 즉시 컴파일 데이터베이스 생성을 지원하지 않는 이유입니다.

현재, Windows에서 Godot를 코딩하는 유일한 실행 가능한 솔루션(IDE-wise)은 Visual Studio를 사용하는 것입니다. 그렇지 않으면 텍스트 편집기를 사용할 준비를 하십시오.

Scons는 훌륭하고 모든 것이지만 12코어 쓰레드리퍼와 128GB 램이 있고 한 줄 변경을 컴파일하기 위해 Windows에서 12초 이상 기다려야 하는 경우(대부분 Scons가 생각하는 것입니다), 약간 짜증이 납니다.

그러나 Scons의 실제 단점(그리고 이것은 검색에 게으른 것일 수 있음)은 개별 cpp 파일을 컴파일할 수 없다는 것입니다. 전체 프로젝트를 빌드하지 않고 개별 cpp 파일을 컴파일할 수 있다는 것은 생산성을 크게 높이고 온전한 검사기를 제공하는 것입니다.

시간이 걸리는 라인 변경뿐만 아니라 빌드할 것이 있는지 파악하는 데도 시간이 걸립니다...

git-bash에서 실행:

$ time scons -j24 num_jobs=24 vsproj=true platform=windows
scons: Reading SConscript files ...
Configuring for Windows: target=debug, bits=default
 Found MSVC version 14.2, arch amd64, bits=64
YASM is necessary for WebM SIMD optimizations.
WebM SIMD optimizations are disabled. Check if your CPU architecture, CPU bits or platform are supported!
Checking for C header file mntent.h... no
scons: done reading SConscript files.
scons: Building targets ...
[Initial build] progress_finish(["progress_finish"], [])
[Initial build] scons: done building targets.

real    0m16.082s
user    0m0.000s
sys     0m0.030s

단일 대상 파일만 빌드하려면 명령줄에서 지정하십시오.

scons -j24 num_jobs=24 vsproj=true platform=windows <path  to targetfile>/targetfile.obj

CMake의 최신 버전은 이전에 사람들이 그것을 사용하지 않는 이유로 언급한 누락된 기능 중 일부를 추가하고 있다고 덧붙이고 싶었습니다.
Unity 빌드: https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html
미리 컴파일된 헤더: https://cmake.org/cmake/help/latest/command/target_precompile_headers.html

@Nosliwnayr 둘 다 수년 동안 애드온에 의해 지원되어 왔으며 잘 테스트되었으며 이제 포함되기에 충분합니다. 아주 오랫동안 CMake에서 둘 다 할 수 있었기 때문에 CMake를 사용하지 않을 이유가 없었습니다.

@bdbaddog
이해할 수 없습니다. 모든 단일 파일을 수동으로 지정해야 합니까? 그 .obj는 무엇을 합니까?
전체 프로젝트에 어떻게 적용합니까? 개별 파일을 자동으로 다시 컴파일합니까?

나는 컴파일 시간이 더 최적화될 수 있기를 바랍니다. 아무 트릭 없이 거의 즉시 C++ 코드를 컴파일할 수 있다는 것은 신의 선물이 될 것입니다 - Godot가 얼마나 빨리 컴파일되는지 확인한 후, 저는 정말 언리얼 엔진 4로 돌아가기 위해 고군분투하고 있습니다(컴파일 , 45분이 걸렸지 만 이제 엔진이 어떻게 든 더 부풀어 오르고 최대 60 분이 걸립니다. 미친 듯이요)

내 말은 Godot가 훨씬 더 빠르게 컴파일할 수 있는 잠재력이 있다고 생각하고 빌드 시스템을 직접 교체할 것이지만 경험이 0개이므로 말 그대로 무엇을 해야할지 전혀 모릅니다.

@Nosliwnayr
미리 컴파일된 헤더를 피할 수 있습니까? 나는 그것들이 완전한 쓰레기라고 생각합니다. 단순하게 유지하십시오.

그들은 또한 공유 프로젝트를 훨씬 더 성가시게 만들고 내 마음 속에 너무 많은 단점이 있는 끝없는 부풀려짐 - 하지만 이봐, 누군가가 그것을 효과적으로 사용한다면 나는 멋지지만 나에게는 그것들이 더러운 속임수처럼 보입니다. 진정한 최적화를 위해

언리얼 엔진 4를 사용한 후, 20GB의 미리 컴파일된 헛소리에 지쳤습니다. 나는 그것들이 그만한 가치가 없다고 생각합니다. 덜 멍청한 시스템이 있어야 합니다(언리얼 엔진 4, 최대 60 - 나를 위해 80GB, 멋지지 않음)

Godot가 그 방향으로 향한다면, 나는 개발자들이 빌어먹을 정신을 잃었다고 가정할 것입니다.

젠장, 젠장, 차라리 그들이 scons를 고수하도록하고 싶습니다. 그것이 언리얼 엔진 4의 광기의 공을 피한다면, 더 똑똑한 접근 방식은 scons를 완전히 교체하는 대신 scons를 개선하는 것입니다. 완전히 새로운 부러진 엉덩이 컴파일 시스템, 현재 시스템이 작동할 때... 다소간

새로운 시스템을 도입하는 데 필요한 정신적 노력은 우리가 이미 가지고 있는 것을 개선하는 것보다 훨씬 더 높다고 생각합니다. 새로운 컴파일러는 결국 몇 달 동안 기능적으로 손상될 수 있습니다.

나는 그것이 완료되면 지옥에 대해 불평하지 않을 것이라고 확신합니다. 그러나 그러한 중요한 엔진 구성 요소를 사용하면 거의 모든 것을해야합니다. 일단 변경되면 되돌릴 수 없습니다.

@RaTcHeT302 - 지정된 명령줄은 단일 대상(이 경우 개체 파일)(물론 종속된 파일)만 명시적으로 컴파일하려는 경우입니다.

실제로 SCons와 관련된 문제에 대해 불평하는 모든 사람들이 복잡한 빌드 시스템을 더 새롭고 빛나는 다른 시스템으로 전환하는 것을 제안하기보다 문제를 해결하는 데 도움이 된다면 .. 글쎄, 그러한 많은 문제가 해결될 것입니다.

@bdbaddog Scons 는 중간 단계 빌드 파일을 생성하지 않습니다. 컴파일과 동일한 단계에서 "프로젝트 종속성" 단계를 수행하며 분리할 수 없습니다.

MSVC, ninja-build, make, llvm 등 빌드 도구를 사용하기 전에 매번 프로젝트 파일을 생성하도록 CMake에 지시하는 것과 같습니다.

git 분기를 전환하면 적절한 .vsproj 및 .sln 파일을 재생성하기 위해 scons 명령줄 빌드를 수행하지 않고 Visual Studio를 업데이트할 수 없습니다. 과거에 문제가 발생했기 때문에 거의 항상 빌드 분기 변경 사항을 정리합니다.

이러한 중간 파일은 빌드용이 아니라 정적 분석기 및 기타 프로젝트에서도 사용할 수 있습니다.

cmake가 완벽하지 않다는 데 동의하고(저도 그렇게 좋아하지 않습니다) 파이썬의 유연성을 선호하지만 cmake는 테이블의 모든 빌드 도구에 대한 최고의 통합 및 지원을 제공합니다.

포크를 CMake로 변환할 때 대부분의 복잡성은 코드 생성 파일에 있었습니다. 빌드가 복잡하다는 생각은 오류입니다. 빌드는 복잡하기 때문에 scons가 필요하지 않습니다. scons를 사용하기 때문에 복잡합니다.

즉, 내가 작업을 중단한 이유는 2019년(Github 모임에서) GDC에서 수석 개발자를 만났고 더 사용 가능한 것으로 전환할 생각이 전혀 없다고 말했기 때문입니다. 전적으로 Linux에서 빌드하고 실제로 내가 본 바로는 Apple에서 크로스 컴파일을 위한 빌드 도구를 설치하기 위해 승인해야 하는 EULA를 위반하고 있습니다.

담당자의 사고방식은 "목적은 수단을 정당화한다"고 빌드를 소프트웨어로 취급하는 데에는 전혀 관심이 없는 것 같고, 대신 Godot는 빌드를 생성하는 일련의 스크립트로 취급합니다.

나는 코드 생성에 대한 변경 사항을 Godot에 기여하지 않을 것이며(더 읽기 쉽고 빠름에도 불구하고) 이 엔진을 완전히 포기하고 내 삶을 계속 이어갔습니다. 솔직히 말하면 더 행복해요. 엔진에는 이미 상당한 기술 부채가 있으며 특히 C++ 표준 위원회가 툴링 기술 보고서를 작성하고 있기 때문에 약 3년 만에 문제가 될 것으로 보고 있습니다. 어느 정도는 기술 보고서일 뿐이므로 일부 사람들은 이에 대해 의견을 달리할 것입니다.)

부끄럽기도 하다. 내 CMake 빌드는 수많은 문제를 일으키고 쉽게 해결할 수 있는 많은 정적 분석 오류를 포착할 수 있었지만 버그를 신고하거나 수정을 시도하기 위해 GDC에서 개발자와 이 문제에 대해 논쟁하는 데 너무 지쳤습니다. 그들을. 내 에너지와 정신 건강은 다른 곳에서 더 잘 소비됩니다.

scons가 다가오는 C++20 모듈 디자인을 처리할 수 있는 세상은 없습니다. 내가 얼마나 많은 도구를 망가뜨릴 것인지를 외친 것뿐입니다. 그것에 대한 종속성 추적을 처리할 수 없으며 사전 스캔 단계가 필요하므로 종속성 추적이 더욱 느려집니다.

마지막으로 사람들에게 사소한 변경만 허용하는 도구를 개선하려고 하지 말라고 제안합니다. Scons는 여기 사람들이 추구하는 개선 사항을 얻기 위해 처음부터 완전히 다시 작성하고 많은 수의 주요 변경 사항이 필요합니다.

빌드 시스템 변경에 대한 논의가 GDC 2019에서 답변되었기 때문에 이 문제를 종료하는 것이 좋습니다. 하지만 리드는 이 문제에 대해 언급하는 데 시간을 낭비할 가치조차 없다고 생각합니다. 개발의.

기존 빌드 시스템이 100% 플러그 앤 플레이 방식으로 변환된 것처럼 개발자가 전환하지 않을 이유가 없는 것 같습니다.

Linux 에서만 빌드

게임 개발자들이 사용자를 만족시키기 위해 빌드 시스템을 변경하는 데 신경을 많이 썼다는 인상을 받고 싶습니다.

내가 언리얼 엔진을 떠난 이유 중 하나는 엔진이 주로 블루프린트/프론트 엔드 게임 제작을 위해 맞춤화되었기 때문입니다. C++ 모듈에서 도구를 만드는 것은 Unreal에서 매우 고통스럽고 복잡합니다.

지금까지 Godot에서는 꽤 쾌적했습니다. C++ 빌드를 더 빠르게 만드는 것은 커뮤니티에 큰 장점이 될 것입니다.

IIRC에서는 Wine을 사용하여 MSVC 빌드 도구를 실행합니다. 여전히 당신의 요점을 바꾸지 않고 동의합니다.

Linux 에서만 빌드

Godot는 항상 Linux뿐만 아니라 많은 플랫폼에서 빌드 가능했습니다...

IIRC에서는 Wine을 사용하여 MSVC 빌드 도구를 실행합니다. 여전히 당신의 요점을 바꾸지 않고 동의합니다.

공식 Windows 빌드는 MinGW를 사용하여 컴파일됩니다. Linux에서 MSVC를 실행하기 위해 WINE을 사용하지 않습니다.

@marstaik - MSVS 프로젝트 파일을 생성하기 위해 빌드를 전환하고 scons를 실행하는 경우 해당 파일을 대상으로 지정할 수 있어야 하며 전체 빌드를 수행할 필요가 없습니다.

그래서 시도:

scons <path to created MSVS project file>/VSPROJECTFILENAME (replace with actual paths and file name which are generated)

SCons는 완전한 빌드를 수행하지 않고도 이 작업을 수행할 수 있어야 하며 먼저 정리를 수행할 필요 없이 올바르게 수행해야 합니다.
(BTW. 저는 SCons 프로젝트 관리자입니다)

@bdbaddog 해당 명령에 vsproj=True를 추가해야 했지만 작동한 것 같습니다.

Godot src에서:
scons -j24 godot.vxcproj num_jobs=x vsproj=true

편집: 어떤 이유로 -j 플래그도 추가해야 합니다...

@bdbaddog 해당 명령에 vsproj=True를 추가해야 했지만 작동한 것 같습니다.

Godot src에서:
scons -j24 godot.vxcproj num_jobs=x vsproj=true

편집: 어떤 이유로 -j 플래그도 추가해야 합니다...

이러한 플래그의 대부분은 기본 SCons가 아니지만 다양한 패키지(이 경우 Godot)가 SCons를 사용하여 빌드 시스템을 구현하는 방식의 일부입니다.
방법을 찾으셨다니 다행입니다!

왜 SConstruct를 사용하고 다른 빌드 시스템으로 전환하지 말라고 주장합니까???

@tjysdsg 위의 논의는 매우 잘 요약되어 있습니다 :slightly_smiling_face:

빌드 시스템을 변경하기 전에 사전 에 의도가 없음을 수년 동안 분명히 했으므로 이것을 닫겠습니다. 우리는 SCons에 만족하며 그 단점은 도구 자체로 인한 경우 자체 SCons 사용과 업스트림 모두에서 개별적으로 평가할 수 있고 또 평가해야 합니다.

이를 위해 "쿨러" 빌드 시스템으로 전환하는 일은 발생하지 않습니다. 대다수의 핵심 기여자들은 SCons를 사용하는 것에 만족하고 있으며 이것이 우리가 지금 가장 잘 알고 있는 것입니다. 새로운 빌드 시스템으로 전환하려면 구현과 학습 비용이 모두 필요하며, 이것이 문제를 일으킬만한 가치가 있는지는 지금까지 입증되지 않았습니다.

대체로 빌드 시스템 변경은 새로운 기여자로부터 받아들일 수 있는 것이 아닙니다. 내부에서 와야 하며 모든 핵심 기여자가 이를 긍정적인 변화로 보아야 의미가 있습니다. 우리는 소스에서 Godot를 빌드하려고 시도하고 cmake 또는 meson 대신 scons 를 입력해야 하는 것을 좋아하지 않는 새로운 사용자를 기쁘게 하기 위해 빌드 시스템을 변경하지 않을 것 입니다 meson 그들은 익숙합니다. 우리는 또한 선택적 새 빌드 시스템을 도입하려는 시도를 받아들이지 않을 것입니다. 경험에 따르면 이것이 불일치, 버그 및 출력 차이로 이어질 수 있다는 것을 알고 있습니다.

물론 빌드 시스템 변경 비용을 능가하는 명백한 이점이 나열되고 개념 증명과 함께 표시될 수 있다면 마음을 바꿀 수 있지만, 오늘 현재와 여기서 2년 간의 논의 끝에 저는 개인적으로 그렇게 하지 않습니다. 인센티브를 보지 마십시오.

@slurps-mad-rips가 잘 말했습니다.

scons를 사용하기 때문에 복잡합니다.

그리고

내 CMake 빌드는 수많은 문제를 일으키고 쉽게 해결할 수 있는 많은 정적 분석 오류를 포착할 수 있었습니다.

플랫 CMake 심각하게 고려되지 않았 역겨운에서, 나는 도랑 SCons는 많은 이유를 생각할 수 있지만, CMake 오류를 발견 특별히 것을 SCons는 그것을 "가치가"다른 사용 뭔가 할 수 있습니다를 찾을 수 없습니다.

이를 위해 "쿨러" 빌드 시스템으로 전환하는 일은 일어나지 않습니다.

CMake는 "쿨러"가 아니라 표준입니다. 실제로 사용해보면 그 이유를 바로 알 수 있을 것입니다.

물론 빌드 시스템 변경 비용보다 더 큰 이점이 나열되고 작업 개념 증명과 함께 표시될 수 있다면 마음을 바꿀 수 있습니다.

나는 누구든지 마음을 바꿀 수 있다고 확신하지 않습니다. 역시나 @slurps-mad-rips는 확실한 이득을 보였으며 그녀는 모든 작업을 수행했습니다. 이미 완료되었습니다.

개발 과정을 개선하기 위한 그녀의 노력을 완전히 무시하는 것은 Godot 팀의 공식 입장을 나타내는 수치스러운 일입니다.

나는 당신의 고통을 충분히 이해하지만 여전히 다른 사람들의 의견에 동의합니다.
시스템에는
장점과 단점 그리고 일반적으로 동일합니다. 기술적인 이유가 거의 없음
그것을 변경합니다.
정치적인 이유로 그들은 오랫동안 당신에게 좋은 일을 하지 않을 것입니다.
운영. 여러분
다른 것을 선호합니다. 어쨌든 포크를 하는 것을 막는 사람은 아무도 없습니다.
무엇이든
이유, 그래서 나는 이것이 무엇보다 좋다고 생각합니다.

2020년 2월 21일 금요일 오후 1시 38분 dorkbox [email protected]에서 다음과 같이 작성했습니다.

@slurps-mad-rips https://github.com/slurps-mad-rips 가 잘 말했습니다.

scons를 사용하기 때문에 복잡합니다.

그리고

내 CMake 빌드는 많은 정적 분석 오류를 포착할 수 있었습니다.
수많은 문제를 야기했으며 쉽게 해결할 수 있습니다.

CMake가 진지하게 고려되지 않는다는 것이 역겹습니다.
도랑 SCons는 많은 이유를 생각하지만, 특별히 그 CMake의 발견
Scons가 찾지 못한 오류는 다른 것을 사용하는 것이 "할 가치가 있는" 것입니다.

이를 위해 "쿨러" 빌드 시스템으로 전환하는 일은 일어나지 않습니다.

CMake는 "쿨러"가 아니라 표준입니다. 실제로 사용해보면
이유를 즉시 이해하십시오.

물론 명확한 이익이 나열될 수 있다면 마음을 바꿀 수 있습니다.
(및 작동하는 개념 증명과 함께 표시됨)
빌드 시스템 변경

나는 누구든지 마음을 바꿀 수 있다고 확신하지 않습니다. 다시,
@slurps-mad-rips https://github.com/slurps-mad-rips 는 분명한 이득을 보여줬고,
그리고 그녀는 심지어 모든 작업을 수행했습니다... 이미 완료되었습니다.

Godot 팀의 공식 입장을 대변하는 것은 부끄러운 일입니다.
개발 프로세스를 개선하려는 그녀의 노력을 완전히 무시하십시오.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/16014?email_source=notifications&email_token=AAABPU2PBIEK6PFKQ2LDTHLRD6VKVA5CNFSM4ENJ6NN2YY48PONVWWK3TUL52HS4DFVREXG43VMVBW63
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAABPU746R4YFHAI73Z57RTRD6VKVANCNFSM4ENJ6NNQ
.

@dorkbox - cmake가 정적 분석 오류를 찾았습니까? 아니면 llvm의 정적 분석 도구를 통해 실행된 cmake의 컴파일 데이터베이스 출력이 그것들을 찾았습니까?

@bdbaddog , @slurps-mad-rips 이 작업을 수행했으며 그녀에게 물어보는 것이 가장 좋습니다. (llvm의 정적 분석 결과라고 생각하지만 cmake를 통해 빌드 작업을 한 사람은 아닙니다.)

@slapin

기술적으로 변경할 이유가 거의 없습니다.

정적 분석 도구 및 최신 언어 기능 지원은 어떻습니까?

@bdbaddog @dorkbox CMake를 통해 "비정적 로컬에 대한 참조 반환" 및 "버퍼 오버플로"와 같은 항목을 찾기 위해 간단히 clang-tidy를 켰습니다. 나는 또한 몇 가지에 대해 clang-check를 실행했고 몇 가지 더 많은 결과를 얻었습니다. include-what-you-use 도 실행할 수 있었고 불필요한 헤더 포함 항목이 꽤 많이 발견되었습니다.

즉, 실제로 cmake 포트를 "마무리"하지 않았습니다. 이식되지 않은 부분은 JSON에서 파일을 생성하기 위해 일부 파일에서 단순히 f.write 를 호출하는 현재 python 스크립트를 변경하려고 시도한 모든 작업이었습니다. 많은 로직을 제거하고 일반 jinja2 기반 템플릿 생성기로 대체할 수 있었습니다. 이것은 또한 현재 scons 빌드가 스크립트를 실행 파일로 시작하는 Windows에서 수행하는 해킹을 해결했습니다.

그러나 나는 scons 빌드와 패리티를 유지하고 최소한 코드 생성에 대한 변경 사항을 병합하기를 원했습니다. 이것은 소스 파일을 생성하는 데 사용되는 Python 스크립트가 지속적으로 변경되고 이러한 변경 사항을 동기화 상태로 유지하기 때문에 발생하지 않았습니다. 내 jinja2 템플릿화는 좌절의 연습이었습니다.

GDC GitHub 모임에서 수석 개발자들로부터 매우 단호하고 단호한 "아니오"를 받았기 때문에 더 이상 Godot에 기여하고 싶지 않다고 결정했습니다. 내 변경 사항은 원치 않았으며 원하지 않으며 이 문제에 대한 다른 사람의 의견에 무관심합니다. 나는 Godot나 Godot의 어떤 포크에도 기여하지 않을 것입니다. 이 문제에서 수석 개발자를 설득하는 데 행운이 있기를 바랍니다. 하지만 이는 마치 벽돌 벽에 대고 말하는 것과 같습니다. 이 스레드에 있는 모든 사람의 곤경에 굴하지 않고, 움직이지 않으며, 냉담합니다.

따라서 SCons가 llvm 도구에 입력되는 컴파일 데이터베이스를 뱉어낼 수 있으면 SCons에서도 수행할 수 있습니다.

따라서 SCons가 llvm 도구에 입력되는 컴파일 데이터베이스를 뱉어낼 수 있으면 SCons에서도 수행할 수 있습니다.

SCons에 매몰 비용 오류가 있는 것 같습니다. cmake와 같이 더 쉽고 능률적이며 이미 기존 빌드 도구의 일부인 것을 사용하지 않으시겠습니까?

scons 웹사이트에서:

scons와 비교할 때 CMake는 다음과 같습니다.

• 더 빠르게
• 일반적인 작업에 더 적은 코드가 필요합니다.
  
  
  
  • 더 안정적임
  
  
  • scons가 지원하지 않는 Code::Blocks, Xcode 등과 같은 프로젝트로의 출력을 지원합니다.
  
  

@dorkbox - 저는 SCons 프로젝트 공동 관리자입니다. 원하는 기능만 지켜보고 있습니다.

마지막 몇 가지 릴리스와 다음 릴리스에는 성능이 향상되었습니다.

또한 닌자 파일 생성을 위한 PR이 있으며 일부 커뮤니티 회원은 컴파일 데이터베이스 도구를 보유하고 있습니다. 따라서 일부 문제는 다음 릴리스에서 (완전하지는 않더라도 적어도 부분적으로) 해결될 것입니다.

나는 우리가 다루지 않은 Godot 프로젝트에 영향을 미치는 안정성 문제에 대해 알지 못합니다. 미해결 항목이 있으면 알려주십시오.
(다음을 통해 저희에게 연락하십시오: https://scons.org/contact.html)

나는 cmake가 일반적인 작업을 위해 더 적은 코드를 필요로 하는지 잘 모르겠습니다. 합리적인 비교에 관심이 있을 것입니다.

음, 내가 scons로 나를 가장 괴롭히는 것은 평범한 오래된 것을 생성 할 수 없다는 것입니다.
GNU 메이크파일. 닌자 부족 - 나는 그것으로 살 수 있습니다.
또한 CMake 툴체인 및 autotools와 같은 크로스 컴파일 유틸리티 처리
크로스 컴파일 기능은 강한 cmake 약점입니다.
나머지는 IDE 사람이 아니므로 괜찮습니다. 내 IDE는 UNIX 환경입니다.

2020년 2월 23일 일요일 오후 10:05 William Deegan [email protected]
썼다:

@dorkbox https://github.com/dorkbox - 저는 SCons 프로젝트 공동 관리자입니다.
원하는 기능만 지켜보고 있습니다.

지난 몇 가지 릴리스와 다음 릴리스에는 성능이 있었습니다.
개량.

또한 닌자 파일 생성 및 일부 커뮤니티에 대한 PR이 있습니다.
구성원에게는 컴파일 데이터베이스 도구가 있습니다. 따라서 일부 문제는
다음 릴리스에서 (전체는 아니지만 적어도 부분적으로) 해결될 것입니다.

나는 우리가 개발한 Godot 프로젝트에 영향을 미치는 안정성 문제에 대해 알지 못합니다.
다루지 않았습니다. 미해결 항목이 있으면 알려주십시오.
(다음을 통해 저희에게 연락하십시오: https://scons.org/contact.html)

나는 cmake가 일반적인 작업을 위해 더 적은 코드를 필요로 하는지 잘 모르겠습니다.
합리적인 비교에 관심이 있습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/16014?email_source=notifications&email_token=AAABPU5TQQFET5RS2JDRY7TRELCHDA5CNFSM4ENJ6NN2YY3PNVWWK3TUL52HS4DFVEXG43VMVBW63LN
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAABPU6UHPX3HJTWPAFTPATRELCHDANCNFSM4ENJ6NNQ
.