Godot: Рассмотрите возможность переноса системы сборки на Meson или другую систему сборки.

Насколько я понимаю, инструменты системы сборки должны обеспечивать:

• Кросс-компиляция (компиляция для каждой возможной целевой платформы с одной и той же хост-платформы).
  
  
  
  • Под «возможным» я подразумеваю, что хост позволяет это (поэтому macOS и iOS возможны только на компьютере Mac, а из Linux с OSXCross).
  
  
• Способ генерации файлов (перевод из PO, шейдерные классы из GLSL, данные документации из XML).
  
  
  
  • SCons знает, что сгенерированные файлы являются зависимостями, поэтому их изменение вызывает перестройку соответствующих файлов. Это тоже следует учитывать.
  
  
• Множественные цели и параметры в пределах целей (target = debug / release_debug / release, архитектура как x86 или ARM, 32 или 64 бит).
• Параметры для настройки сборки / включения дополнительных целей (оболочка gdnative, без моно-клея, включение / отключение: модули, драйверы, устаревшие функции и т. Д., Установка статической компиляции библиотек с использованием встроенного кода или использование системных библиотек для каждого один индивидуально).

Я не знаю Meson, но если он предоставляет все, что указано выше, все должно быть в порядке (если я что-то не забыл). Конечно, кому-то придется пережить мучительную боль, переписав систему сборки в Meson, а затем показать, что инструменты и время сборки для Godot лучше, чем для SCons.

Обратите внимание, что для некоторых сторонних зависимостей требуется, чтобы патч был скомпилирован с помощью Godot. Я заметил, что у Wrap есть поддержка патчей, но похоже, что патч должен быть где-то доступен для загрузки, хотя я думаю, что им легче управлять, если они все еще являются частью репозитория. Кроме того, для некоторых из них требуются специальные флаги компиляции, которые не следует применять ко всей сборке.

Я думаю, что такое доказательство концепции было бы очень ценно, потому что

• это дает нам лучшее представление о том, обрабатывает ли новая система сборки все, что нам нужно, и насколько хорошо она это делает
• он дает нам конкретные, а не абстрактные данные для обсуждения

Что касается второго пункта, это означает, что мы можем видеть разницу в скорости сборки для Godot , мы можем видеть, насколько проще (или сложнее) становятся наши сценарии сборки, и мы можем легче сравнивать различия, чтобы сделать выбор вместо того, чтобы делать выбор предположения, основанные на том, что, по вашему мнению, он может предложить.

-

Теперь лично я должен сказать, что я ни за, ни против этого, но я думаю, что есть более низко висящие плоды, за которыми нужно гнаться, вместо (или раньше?) Изменения всей системы сборки. Особенно в этот критический момент, когда нужно как можно больше рук, чтобы убедиться, что 3.0 и первые патчи находятся в наилучшей возможной форме. Но если мы хотим улучшить систему сборки, я бы посмотрел на время сборки CI и сложности, связанные с ситуацией сборки Mono. (Я думаю , что это на akien «ы TODO / список aggrievances?)

Кроме того, ошибочные параллельные сборки в Windows - отстой, но это больше связано с личным «желанием было бы хорошо, если бы это было исправлено».

TL; DR:

• Я согласен, что документация / ресурсы SCons отсутствуют, сценарии сборки просты, Python несколько противодействует этому, IMO
• Как новый участник, система сборки Godot была одной из наименее раздражающих в настройке, очень мало времени до первой успешной компиляции.
• Я бы предпочел, чтобы усилия были потрачены на улучшение 3.0 / 3.1 как можно больше, и, возможно, подумал бы об этом, когда они станут стабильными.
• Лучшее время сборки CI и более легкая сборка Mono могут быть важнее

Мое мнение. :)

Я абсолютно уверен, что выпуск 3.0 и сосредоточение внимания на следующих выпусках (3.0.1, 3.1) должны иметь приоритет перед этим, для протокола.
Я знаю , почему люди не любят работать на buildsystems (так как это действительно только на благо других разработчиков / в частности , технически подкованных конечных пользователей - которая не является ООН важно, это стоит сделать жизнь разработчики и вкладчиками легче , но в конечном итоге цель - это счастье конечных пользователей) и есть вся эта штука с «альтернативными издержками», т. е. когда время, потраченное (или потерянное / потраченное впустую, в зависимости от того, кого вы спросите) на улучшение системы сборки, может быть потрачено на улучшение самого проекта. (Если только вы не похожи на меня и все равно не умеете работать на стороне C ++.)

И, в конечном итоге, SCons действительно «просто работает», что для большинства разработчиков, вероятно, будет достаточно хорошим, так что, хотя я надеюсь, что в конечном итоге это произойдет, я не задерживаю дыхание для этого для 3.1 или даже 3.2, если он даже получит достаточно поддержки, чтобы над ним поработать с самого начала.

Все это говорит о том, что я могу запустить POC позже на этой неделе в своей вилке для тех, кто желает следить за прогрессом в этом (и, вероятно, помочь мне, так как у меня нет большого опыта написания систем сборки), но я, скорее всего, пока не буду открывать для этого пул-реквест.

Я не нахожу SCons медленными, а его гибкость (которой мы пользуемся), вероятно, не имеет себе равных. SCons также очень хорошо зарекомендовал себя, я считаю, что он никогда не портит сборку.

Честно говоря, если кто-то добровольно не переписывает всю систему сборки (а не просто доказательство концепции) и не показывает, что она либо проще (намного меньше кода), либо намного быстрее , я бы даже не стал рассматривать что-либо другое, даже немного.

Теперь лично я должен сказать, что я ни за, ни против этого, но я думаю, что есть более низко висящие плоды, за которыми нужно гнаться, вместо (или раньше?) Изменения всей системы сборки.

На самом деле это не повредит этому изменению. Я имею в виду, что большинство участников Godot работают в свободное время и работают над тем, что хотят. В случае @NullConstant кажется, что это либо «делай это, либо ничего не делай» (не говоря уже о том, что вы не хотите что-то исправлять, просто труднее работать с фактической базой кода C ++ и искать ошибки в чем-то незнакомом), поэтому в целом это хорошо.

Кроме того, аргумент «есть дела поважнее» - это способ ничего не делать, ИМО. Конечно, ничего не будет объединено, пока мы не будем уверены, что это не сломает ничего и не будет сделано ближе к выпуску. Я согласен, что есть более важные вещи, но это не значит, что это нельзя начинать.

Дело в том, что кто-то, кто этим занимается, скорее всего, будет делать это в одиночку. Конечно, основные разработчики могут ответить на конкретные вопросы, но больше этого не произойдет. Поэтому SCons никогда не считался замененным: пока никто не хотел пачкать руки. Как я уже говорил о Bullet раньше: кто-то должен заставить его работать и доказать, что это возможно и лучше, иначе мы останемся с существующим статус-кво.

Я действительно думаю, что SCons медленный. Не очень медленно, но такие вещи, как статус выполнения и кеш, замедляют его при перестроении (использование дискового ввода-вывода для чтения из кеша делает его медленным), поэтому я отключаю их при перестроении. Чтобы начать что-то делать, нужно немного времени, после чего это довольно быстро.

Не знаю, будет ли Meson значительно быстрее, но если кто-то захочет попробовать, я не против.

Конечно, если кто-то найдет время, чтобы сделать это, и покажет, что это улучшение, достаточное для перехода, я за это :)

Как я уже сказал, у меня нет особых возможностей заниматься поиском ошибок C ++ или добавлением новых функций на этом фронте, поэтому я могу сделать это вместо этого.

Я полагаю, что это дает мне (и / или кому-либо еще, кто будет работать над этим в будущем) довольно четкую двоякую цель, которую нужно достичь:

• заставить Godot скомпилировать с Meson в любой форме для начала
• сделать это так же просто, как SCons в данный момент, возможно, даже в большей степени (за счет повышения скорости)

И я полагаю, что скорость SCons не ужасно-ужасная (большая часть времени процесса сборки в любом случае связана с фактическим связыванием и компиляцией, поэтому замедление из-за накладных расходов системы сборки, вероятно, несколько незначительно), но это, безусловно, могут быть улучшены, и предложение Meson в качестве альтернативы может быть именно таким улучшением. Посмотрим.

Самая большая проблема, вероятно, заключается в замене скриптов сборки python для автогенерирования кода, такого как шейдеры, не похоже, что у meson есть такая функция.

и предложение Meson в качестве альтернативы могло бы стать таким улучшением. Посмотрим.

Это не должно быть альтернативой: мы либо переходим к нему, если он явно лучше, либо даже не предлагаем его. Необходимость поддерживать две системы сборки - безумие.

Правильно, это честно.

Я собираюсь заняться этим в течение следующих нескольких дней / недель, посмотреть, пойдет ли это куда-нибудь и действительно ли это усилия, которые стоит предпринять (даже если я в конечном итоге останусь единственным человеком, работающим над этим все время).

Я сообщу, если получу что-нибудь презентабельное (например, тест).

Хотя это не мезон, я сделаю тест в ближайшие недели, чтобы увидеть, что нужно для сборки godot под bazel для Windows 64 bit под msvc.

Bazel - еще одна система, преимуществом которой является более короткое описание сборки и более быстрая сборка. Кроме того, он поддерживается Google, поэтому никуда не денется.

В любом случае, я не могу это проверить, но очень вероятно, что 99% вычислительного времени, затрачиваемого на сборку Godot, тратится на компилятор. Таким образом, даже если бы накладные расходы на программное обеспечение для сборки отсутствовали, это привело бы к уменьшению времени сборки на 1%. Даже 5% -ное снижение не будет иметь смысла, если оно не позволит уменьшить количество кода и повысить надежность (или если я ошибаюсь :)).

Что касается скорости сборки чистого клона, я сомневаюсь, что она будет иметь существенную разницу. Но это может быть значительным, если учесть скорость восстановления. SCons всегда перестраивает множество вещей, которые не были изменены, когда я беру новый коммит (особенно OpenSSL и Bullet, которые являются большими библиотеками и требуют времени для сборки).

Как я уже сказал, SCons запускается медленно (требуется несколько секунд, прежде чем действительно начнется компиляция). Если вы создаете весь исходный код, который незначителен, но если вы только изменили строку и компилируете для тестирования, это может значительно улучшить рабочий процесс (какой IMO является наиболее важным в системе сборки: помогите людям, которые работают с кодом) . Таким образом, уменьшение на 5 секунд за 10-минутную сборку не имеет значения, но уменьшение на 5 секунд за 10-секундную перестройку - это серьезное улучшение.

Но я согласен , что любое изменение в связи с этим должны быть проверены много , чтобы доказать это работает. Как заявил @reduz , SCons никогда не испортили сборку, и это следует учитывать.

Bazel - еще одна система, преимуществом которой является более короткое описание сборки и более быстрая сборка. Кроме того, он поддерживается Google, поэтому никуда не денется.

В Википедии даже растет категория «вещей, прекращенных Google». :)

@mhilbrunner Нет, он все еще поддерживается https://github.com/bazelbuild/bazel

Их точка зрения заключалась в том, что то, что это сделал Google, не означает, что он будет существовать еще долго.

Поскольку мы применили C # для разработки игр, мы могли бы попробовать что-нибудь вроде Cake . Я сам не пробовал, поэтому мне интересно, что вы думаете по этому поводу. Во-первых, по крайней мере, скрипты будут работать быстрее, чем на Python.

Поскольку мы применили C # для разработки игр, мы могли бы попробовать что-нибудь вроде Cake .

Я не уверен, что установка Mono для компиляции Godot - хорошая идея, учитывая, что Godot в основном является проектом C ++ и может быть скомпилирован без поддержки C #.

Уровень производительности, предлагаемый Meson или CMake (с генератором Ninja), должен быть более чем достаточным для целей Godot.

@Calinou, вы, вероятно, правы, хотя кажется, что все запрыгнули на подножку C #, лично я использую его для написания сценариев игр с Godot и приложений для повышения производительности с Xamarin.Forms, а также, если я действительно хочу снизить производительность, я могу попробовать что-то вроде конвертер IL2cpp или сразу переходите на C ++. Я также подумываю использовать mono / csharp REPL и ASP.net для вещей, для которых я обычно использую JavaScript, Python или PHP, например, связанные с веб-разработкой вещи или сценарии оболочки. Дело в том, что я был бы не против иметь систему сборки, основанную на C #, поскольку я бы уже использовал ее практически для всего. По крайней мере, для меня это был бы конец «черт возьми ... еще один язык, который мне нужно выучить ... почему бы им не придерживаться C ++ и - не вставить сюда достойный динамический / управляемый язык -»

Редактировать:

Чтобы уточнить, необходимость установки Mono Framework для сборки Godot звучит для меня не так плохо, поскольку так называемые игровые движки AAA требуют гораздо больше дискового пространства:

• Годо <50 МБ
• Godot с поддержкой Mono (<50 МБ) + Mono Framework (~ 350 МБ) = ~ 400 МБ
• Unreal ~ 20 ГБ
• Unity ~ 10 ГБ
• CryEngine ~ 8 ГБ

Кроме того, мы могли жестко запрограммировать поддержку Mono в редакторе по умолчанию и иметь некоторую логику, чтобы определять, поддерживать ли сценарии C # или нет во время выполнения, и запрашивать структуру Mono или соответствующие шаблоны экспорта.

Мне нравится CMake, и meson выглядит круто, но я склонен согласиться с этой статьей: http://www.rojtberg.net/1481/do-not-use-meson.

Мне очень интересно поработать ногами, чтобы перевести Годо в Meson. Единственное, что в настоящее время мешает мне участвовать в Godot (и использовать его), - это Scons. Мне пришлось использовать его много лет назад, и у меня никогда не было более болезненного опыта инкрементальной разработки за всю мою жизнь.

В приведенной выше статье есть много соломенных аргументов, утверждающих, что CMake уже существует, и мы должны просто использовать его. Файлы сборки Meson очень легко читать, и в них используется синтаксис, близкий к синтаксису Python. Преобразование может быть быстрым. Я пишу в этой теме, потому что, если работа была сделана, будет ли вообще рассматриваться запрос на слияние для слияния?

Я пишу в этой теме, потому что, если работа была сделана, будет ли вообще рассматриваться запрос на слияние для слияния?

Это будет рассмотрено, но должно быть доказано его преимущество перед SCons.

Если вы считаете CMake просто еще одной системой сборки, а не стандартом де-факто, у вас будет слишком много вариантов. Почему мезон над SCons? Или bazel / buck тоже неплохие инструменты? Но самый большой аргумент в пользу CMake - это инструмент, созданный для поддержки этой экосистемы. Базы данных компиляции Clang, поддержка упаковки для нескольких операционных систем и т. Д. Единственные существенные недостатки, которые я слышал, - это плохой синтаксис и документация, но на самом деле этого недостаточно, чтобы изменить свою позицию по этому поводу.

Почему мезон над SCons?

Meson генерирует файлы ниндзя, что намного быстрее для инкрементальной разработки. Кроме того, в Windows вам не нужно выполнять какие-либо манипуляции с путями в Visual Studio. Мезон работает "из коробки". Использование meson вместо scons уменьшит накладные расходы на окна таргетинга, особенно для тех, кто хочет использовать Visual Studio (из которых, я должен отметить, что meson может генерировать проекты так же, как CMake)

Или bazel / buck тоже неплохие инструменты?

Учитывая, что bazel и buck написаны на Java (зависимость godot есть только в том случае, если вы нацеливаетесь на android, и даже тогда можно технически использовать только NDK), я бы сказал, что они прямо как основная зависимость для всех пользователей. Python уже находится в списке зависимостей, и вы можете легко установить мезон (и ниндзя) с помощью быстрого pip install meson

Базы данных компиляции Clang

Meson поддерживает это по умолчанию, так как это функция по умолчанию, встроенная в ниндзя.

поддержка упаковки для нескольких операционных систем

Meson также поддерживает это и в соответствующих случаях в значительной степени полагается на pkg-config.

Единственные действительные недостатки, которые я слышал, - это плохой синтаксис и документация.

У Meson очень похожий на Python синтаксис, основанный на переменных, объектах и ​​встроенных функциях. На мой взгляд, написание

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 - это не автоинструменты».

Но прежде всего (и я думаю, что это действительно важная вещь, особенно для тех, кто использует godot как gdnative), Meson изначально поддерживает предварительно скомпилированные заголовки. CMake этого не делает (а использование cotire для взлома сборки может вызвать больше проблем, чем оно того стоит).

Я не могу сказать вам, насколько это может ускорить сборку для пользователей gdnative, но это будет значительным приростом для gcc и msvc (по крайней мере, увеличение производительности на msvc неизбежно). Добавьте использование extern template для очень небольшого количества шаблонного кода, найденного в godot, и вы увидите приличное улучшение времени сборки, которое важно для итеративных и инкрементных сборок.

Meson генерирует файлы ниндзя, что намного быстрее для инкрементальной разработки.

Обратите внимание, что CMake также может генерировать файлы сборки Ninja вместо традиционных файлов Makefile; это делается путем передачи -G Ninja в его командную строку. Он довольно хорошо работает в большинстве проектов, которые я пробовал, и в целом немного быстрее (плюс, по умолчанию он будет использовать все потоки ЦП).

Meson по-прежнему выигрывает в необработанных сравнениях производительности, которые я видел, но это определенно помогает сократить разрыв между производительностью Meson и CMake.

Да, однако, CMake не устанавливает для вас Ninja автоматически и не является генератором по умолчанию. По моему опыту, большая часть времени CMake тратится на настройку проекта, и хотя последние версии CMake значительно улучшили производительность, не у всех будет последняя версия CMake.

Хорошо, это довольно тщательно! Я рад, что у вас есть хорошее представление о функциях, которые вы цените в системе сборки. Я по-прежнему считаю, что в мире C ++ должна быть стандартная система сборки, на которую могут полагаться проекты. Я просто хочу, чтобы мезон был транспилятором CMake, а не сам по себе.

Я по-прежнему считаю, что в мире C ++ должна быть стандартная система сборки, на которую могут полагаться проекты.

Поверьте, никто не хочет этого больше, чем я. Я стал своего рода мусорным гоблином системы сборки и даже рассказывал о них на CppCon. К сожалению (или к счастью?) Я очень забочусь о системах сборки, почти до одержимости. :)

Я просто хочу сказать это, но каждый раз, когда я делал длинную сборку Godot в Windows, я отмечал, что Python постоянно занимал> 15% моего процессора. Я сомневаюсь, что он запускается медленно.

Кто собирается сделать небольшой прототип двигателя Godot, построенный с использованием мезона? Я так и не дошел до создания небольшого теста для bazel.

Двухмерной сборки Godot должно быть достаточно для тестирования со всеми отключенными параметрами.

Первым препятствием, с которым я столкнулся, был core / make_binders.py. Это автоматически сгенерированный код, который использует godot.

Я сделал начальный прототип в системе сборки Bazel, но я расскажу о настройке по другому вопросу. https://github.com/godotengine/godot/issues/18518

У вас нет времени на неделю, но другие могут расширить Bazel BUILD.

Лол, как Базель вмешался?

Поскольку может быть единовременная возможность переключиться на другую систему сборки, не должны ли мы искать наилучшие возможные варианты? Мне, например, было бы интересно увидеть сравнительную таблицу Cake vs Bazel vs Scons, хотя я должен признать, что у меня нет опыта работы с Cake, чтобы выполнить эти тесты.

@rraallvv вы имеете в виду Cake или CMake?

@isaachier Мое плохое, я говорил о www.cakebuild.net , я должен был быть более конкретным, извините за это.

Разве это не только для C #?

@isaachier Я действительно не знаю, все это время я предполагал, что Cake способен на это, точно так же, как SCons, написанные на Python и поддерживающие C ++. Тем не менее, я просто спросил в их gitter-чате , я повторно отправлю здесь ответ.

@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. Использует Python.
• meson : Новая крутая система сборки на основе Python, не очень медленная. Главный недостаток - траектория. Неясно, будет ли это просто еще одним изюминкой недельной системы сборки.
• Автоинструменты : древние, без поддержки инструментов (например, компиляция баз данных для поддержки автозаполнения Clang или статического анализа). Нет поддержки Windows. Избегайте любой ценой.
• bazel : менеджер пакетов / система сборки Google в одном Hunter . Кроме того, программное обеспечение Google имеет тенденцию сосредотачиваться на том, что нужно Google, а не на широкой публике. Слишком ново, чтобы определять долгосрочную траекторию.

Я стараюсь продвигать CMake всякий раз, когда у меня есть возможность, потому что мне нужен стандарт де-факто для C ++, а у CMake сейчас самая большая «доля рынка».

@isaachier Спасибо, что поделились этой информацией, я продвигаю C #, поскольку нет системы сборки, поддерживающей сценарии на C ++, это может показаться глупым, но я не знаю, почему кто-то еще этого не сделал, например этот C ++ REPL можно использовать для системы сборки, если кто-то хочет перейти на следующий уровень и закончить споры о том, какой из них лучше, быстрее и т. Д.

Я не понимаю. C ++, вероятно, был бы ужасным языком сборки. Медлительность больше связана с ядром внутренней системы сборки AFAIK, а не с деталями используемого языка сценариев.

@isaachier Я предполагаю, что SCons настолько медленный, потому что он был написан на Python, но если бы кто-то взял на себя задачу переноса всей системы сборки на C ++, а также заставил ее JIT-компиляцию сценариев C ++ для запуска этих сборок, это было бы намного Быстрее. Возможно, то же самое может быть верно для каждой системы сборки.

Это хорошая идея, но мезон не считается медленным большинством пользователей, но он написан на Python.

Я сомневаюсь, что мезон станет изюминкой недели, поскольку проект GNOME в настоящее время отказывается от автоинструментов в пользу мезона.

Кроме того, Scons работает медленно не потому, что он написан на Python, а потому, что он также выполняет сборку. Это система прямой сборки, такая как make или ninja, но она также использует огромное количество XML для определений, и большая часть ее кода на самом деле является просто преобразованием XSLT.

Meson, с другой стороны, выполняет свои сценарии сборки для создания дерева зависимостей, а затем выгружает его в файл ниндзя. Мезон быстр, потому что ниндзя быстр. Кроме того, в Meson не все является строкой, как в CMake.

Наконец, я должен отметить, что есть несколько систем сборки для разработки, в которых вы сможете писать сценарии на C ++ (я на самом деле пишу один из них). Однако я прошу Godot перейти на систему сборки, которая еще не существует ( и того хуже, что пишу сам) немного высокомерно, на мой не столь скромный взгляд;)

Я также хочу повторить, что в текущем рабочем процессе разработки питон является необходимостью. То же самое и с мезонами. И это делает переход на meson таким же простым, как вызов инструмента pip в Python.

Я полностью согласен с @reduz, что я тоже не считаю SCons медленными.

Как сказал @ slurps-mad-rips:

Scons работает медленно не потому, что он написан на Python, а потому, что он также выполняет сборку

мужские бра:

scons поддерживает создание нескольких целей параллельно с помощью опции -j, которая принимает в качестве аргумента количество одновременных задач, которые могут быть созданы:
scons -j 4

У меня процессор с 8c16t, поэтому использование scons p = x11 -j 18 очень быстро для меня.
Это в 10 раз быстрее, чем использовать «scons p = x11» в качестве значения по умолчанию «-j 1».
Есть ли у кого-нибудь одноядерный процессор в 2018 году?
Пусть ваш процессор работает полностью.
пожалуйста, попробуйте.

Не у всех есть эти большие процессоры, но, что более важно, мезон (ну, ниндзя) намного быстрее при инкрементных перекомпиляциях. Scons по умолчанию выполняет хеш-сумму MD5, чтобы узнать, изменился ли файл. Godot использует параметр MD5-timestamp, что означает, что он будет хешировать файл только в том случае, если временная метка изменилась. Это все еще смешно.

Думаю, лучший способ доказать, что лучше - написать новое и посмотреть :)

Scons не является быстрым для многих людей, особенно для пользователей Windows, которые сталкиваются с проблемами с чем-либо выше -j 1.

@ slurps-mad-rips это зависит от проекта. ниндзя, кажется, слишком сильно раздувает свою скорость. См. Эту статью: http://david.rothlis.net/ninja-benchmark/. Кажется, здесь лучше всего будет подсчитывать исходные файлы. Если <20K, особой разницы не будет.

@isaachier этот тест находится между make и ninja, а не ninja и scons, так что вам придется меня простить, если я не хочу обращать на это внимание. ;)

Думаю, лучший способ доказать, что лучше - написать новое и посмотреть :)

Согласен, сбрасывать байк смысла нет. Если у вас есть мнение о лучшей системе сборки, внедрите ее и докажите, что она лучше. В противном случае это обсуждение мнений и ни к чему не приведет. @fire уже провел частичный тест с bazel: https://github.com/godotengine/godot/issues/18518.

@ slurps-mad-rips - это совсем другая тема, а не SCons. Я просто имел в виду, что make vs. ninja - это не безумная разница.

Небольшое обновление: я отказываюсь от попыток перейти на мезон. Это было разрозненно, и, хотя файлы сборки немного легче читать, большая часть моего (теперь редкого и дефицитного) свободного времени тратится на то, чтобы оставаться в курсе текущей системы, вместо того, чтобы переносить scons на meson.

Прямо сейчас большой объем кода и операций помещается непосредственно в скрипты scons, что затрудняет переход на другую систему сборки. Во всяком случае, я бы сказал, что время должно быть потрачено на развязку существующих скриптов python, которые генерируют код из scons, так как это значительно упростит переход на другую систему сборки, такую ​​как meson, cmake или даже bazel.

Хорошо, что патч просто слили, чтобы убрать всю генерацию кода. https://github.com/godotengine/godot/pull/17595 Не сдавайтесь!

Со-менеджер проекта SCons здесь. Пара заметок:
1 - SCons находится в стадии активной разработки, и с момента перехода на Github мы наблюдаем увеличение количества запросов на вытягивание.
2 - Мы определили несколько конкретных частей SCons, на которые приходится около 50% времени нулевой инкрементальной сборки, и активно работаем над решением этой проблемы. (Функциональность Subst)
3 - Мы начали поддерживать Python 3.5+ (а также 2.7.x) с SCons 3.0
4. Позвольте мне предположить, что вместо того, чтобы пытаться портировать на N различных систем сборки, более эффективно использовать время разработчика, потратив некоторое время на улучшение SCons.
5 - Мы определили и обратились с помощью профилирования некоторых низко висящих плодов повышения производительности, которые были выпущены в версиях 3.0.0 и 3.0.1. Если вы используете более раннюю версию, нулевая инкрементная сборка может быть на 5-15% медленнее. (при условии Python 2.7.x)

Как всегда, проект SCons готов помочь проектам, использующим SCons, с проблемами, с которыми они сталкиваются.

Некоторая "статистика" для SCons и godot.

Я использовал (и до сих пор использую) Q6600, который представляет собой четырехъядерный процессор с 2008 года или около того с частотой 2,4 ГГц (и меньшим количеством инструкций на цикл), чем процессоры, которые мы «все» используем сегодня (i7).

На Q6600 сборка занимала от 3 до 5 минут (или больше, но точное число не так важно), из которых ~ 35-40 секунд были потрачены SCons на разбор дерева зависимостей и прочего (подготовительная работа) ... Таким образом, 80% времени тратится на многократный запуск процесса cl.exe (компилятор MSVC).

Итак, с точки зрения производительности и оптимизации, если SCons (на самом деле python, а не SCons) имеет ужасную систему вызова процессов, которая занимает больше времени, чем должна, или некоторые другие инструменты не компилируют один файл для каждого процесса (например, SCons в настоящее время) и 1 накладные расходы на один файл значительны (я не эксперт по внутренним компонентам и накладным расходам на запуск cl.exe), единственная оптимизация производительности, которую может произвести более быстрая система сборки, вероятно, связана с этапом построения дерева зависимостей и другими подготовительными работами для усложнения .

Итак, мы оптимизируем эти 35-40 секунд из 5-минутной сборки (сейчас на i7 мы, вероятно, оптимизируем 20-секундный шаг настройки одного ядра из 3-минутной многоядерной сборки).

Итак, напомним, если я правильно помню, от 3 до 5 минут - это на самом деле 4-ядерная многоядерная сборка, в то время как сборка с одним ядром занимает около 10? Мне нужно повторить тесты ...

Итак, «оптимизация» SCons означает более или менее оптимизацию тех первых 35 секунд начала сборки ...

Это что касается "оптимизации", когда дело доходит до SCons по сравнению с другими более быстрыми системами сборки ... Возможно, что фактическую компиляцию можно немного оптимизировать, избегая вызова одного cl.exe для каждого файла obj, но это только в том случае, если накладные расходы процесса значительны (я боюсь, что жесткий диск всегда будет фактическим узким местом ввода-вывода (а не ЦП), чего нельзя избежать / уменьшить без SSD)

Все вышеперечисленные абзацы относятся к «полной сборке». Тем не менее, SCons "обманывает", если все уже построено, и проходит тяжелые проверки согласованности, поэтому, если вы измените один файл, он фактически скомпилирует "один файл", а затем свяжет все обратно, превратив "полную сборку" в несколько инкрементальной сборки). Однако для этого требуются эти 35-40 секунд предварительного вычисления полного дерева зависимостей ...

Итак, «инкрементная сборка» на моем старом компьютере занимает около 45 секунд, и, когда я был новичком 2 года назад, я думал, что это будет связано с процессором, но на самом деле это может быть связано с вводом-выводом (проверка нескольких тысяч файлов на жестком диске ) для полной развертки зависимостей / перестройки дерева ... Итак, если это связано с вводом-выводом, никакая "более быстрая строительная система" не решит эту проблему ...

Моя хакерская идея, появившаяся 2 года назад, заключалась в том, чтобы попытаться прикрепить «наблюдатель» файловой системы к SCons, запустить SCons и перекомпилировать один измененный файл (и его зависимости, это происходит автоматически), а затем просто снова связать все обратно ... хотя сегодня я понимаю, что связывание все равно, вероятно, будет запускать полную развертку зависимостей ... при этом очистка / восстановление дерева зависимостей может быть прекращена с помощью опции, а затем SCons будет использовать его кэшированное дерево деп ... что экономит около 15-20 секунд из 35-секундного шага предвычисления (первые 15 секунд кажутся неизбежными), хотя это может не гарантировать «идеальную» сборку всегда, как это делает SCons (хотя это может быть не важно для инкрементных сборок в dev ... если вы решите, что скорость достойный компромисс).

Теперь у меня достаточно знаний, чтобы я мог, вероятно, взломать его через npm и npm watch ... или другую систему, с которой я в настоящее время не знаком ... Но это на потом, и когда у меня будет время (пока нет).

Это становится слишком длинным, поэтому я закончу на этом, но смысл этих параграфов был в том, чтобы дать вам некоторую «статистическую» информацию, а не отговаривать кого-либо (продолжайте, если вам нравится работать над системами сборки), как мне самому нравилось исправление некоторых вещей в SCons Годо. Я надеюсь, что некоторая информация была полезна для вас, ребята.

Если вы хотите воспроизвести / повторить мою статистику, просто просмотрите документы SCons, пока не включите статистическую информацию (таймеры) и / или найдите способ отключить повторное преобразование зависимостей (эти первые 20–30-35 секунд «предварительного вычисления» ) ...

Или для немного менее ручного решения информация отладки таймера уже должна присутствовать (отредактируйте: вероятно, нет, кто-то сделал то, что выглядит как приятное обновление для генерации проекта vs, этот абзац может быть устаревшей информацией) в автоматизированном проекте VS, созданном с помощью SCons (в конце файла SConstruct) ... вы можете найти информацию о том, как сгенерировать VS Project, в «Руководстве по компиляции Windows» на веб-сайте godot. Затем вы можете запустить SCons из VS, я считаю, что сгенерированный проект, вероятно, все еще должен работать, хотя я не тестировал его в Godot 3 ... Это вариант, но добавление scons в> log.txt также является другим вариантом (и т. Д.) ...

Надеюсь, кто-то сочтет эту информацию полезной.

@Griefchief Просто чтобы немного прояснить ситуацию, я думаю, что мы не пытаемся оптимизировать время полной сборки, так как в любом случае время компилятора доминирует. Вместо этого мы хотим оптимизировать инкрементные сборки, в которых изменяется только один исходный файл.

Действительно, «нулевая инкрементальная сборка» (на самом деле ничего не нужно перестраивать, но scons все равно нужно будет обработать все дерево зависимостей, чтобы гарантировать это) - это тот случай, над которым мы работаем.

Некоторое профилирование выявило некоторые недостатки в обработке командных строк (которые должны выполняться для каждой цели, чтобы гарантировать, что они не изменились). Основная часть этого - логика Subst (). Это довольно сложный код, который до сих пор реализовывался более простым и безопасным, но не ужасно эффективным способом.

Еще одна горячая точка времени - это чтение и запись файлов sconsign, которые в настоящее время реализованы с помощью cpickle и всегда читаются и записываются как единое целое. У нас есть несколько идей о том, как ускорить и / или сделать более постепенным. В любом случае следите за улучшениями в будущих выпусках.

Кстати, вы можете попробовать MSVC_BATCH, чтобы узнать, ускоряет ли это сборку Windows:

MSVC_BATCH
Если задано любое истинное значение, указывает, что SCons должны выполнять пакетную компиляцию объектных файлов при вызове компилятора Microsoft Visual C / C ++. Все компиляции исходных файлов из одного исходного каталога, которые генерируют целевые файлы в одном и том же выходном каталоге и были настроены в SCons с использованием одной и той же среды построения, будут построены за один вызов компилятора. Только исходные файлы, которые были изменены с момента создания их объектных файлов, будут передаваться при каждом вызове компилятора (через конструктивную переменную $ CHANGED_SOURCES). Любые компиляции, в которых базовое имя объектного (целевого) файла (за вычетом .obj) не совпадает с базовым именем исходного файла, будут скомпилированы отдельно.

@ bojidar-bg да, да, на самом деле я тоже говорил об инкрементных сборках, спасибо за совет: D

@bdbaddog Привет, плохой пес, просто для твоей информации, я написал этот большой свой комментарий еще до того, как увидел твой комментарий, так что он на самом деле не относится ни к чему конкретно в твоем комментарии ... но тебе удалось упомянуть некоторые из " проблемы "У меня была (информация для других людей), когда мы оба писали наши комментарии одновременно ...

И я не хотел пинговать вас в этом, потому что я не хотел "тратить" ваше время: D, но я думаю, что я сделаю это, если в будущем потрачу еще немного времени на сборку / сборку godot (я действительно планирую, я просто очень занята))

Спасибо за ваш вклад!

@bdbaddog BD, поскольку вы предоставляете поддержку, могу я спросить здесь:

Если я прикреплю npm watch к файловой системе (исходный код godot) и буду знать, какой именно файл был изменен, принесет ли это мне какие-то преимущества с SCons?

Теперь я могу запустить scons через npm watch и отправить туда файл ...

scons [godot options] / файл /, который / был / изменен.

это, очевидно, перекомпилирует этот файл, вероятно, избегая всего дерева депов Годо? верный? Итак, теперь обход дерева депозита займет не 20 секунд, а менее 1 попытки, но я получаю 1 обновленный файл .obj (или больше, в зависимости от того, что вы меняете). На самом деле он не будет проходить через все дерево godot dep для этого одного файла? У меня есть преимущество в меньшем обходе дерева деплоя в этом примере (и, возможно, другие преимущества на этапе предварительного вычисления, которые нельзя получить за счет повторного использования кеша дерева деплоя, например, меньше файлов в целом, чтобы пройти?)?

Теперь, если у меня есть преимущество, и если бы я хотел просто связать все снова, нужен ли мне полный обход дерева для «простой» фазы связывания?

Я понимаю, что этот вариант использования может в настоящее время не поддерживаться Scons (просто свяжите все снова), но я спрашиваю как с практической, так и с теоретической точки зрения? Я понимаю, что кэшированное дерево депов может быть повторно использовано с опцией «не делать дерево депов» (я забыл об этом, прошло два года), и это будет работать для некоторых вариантов использования, и этот вариант использования - это не добавленные новые файлы, исправьте ? (npm watch может предупредить меня о добавлении нового файла, и я мог бы затем выполнить полное обновление дерева депов, если обнаружу это ... другими словами, отодвинуть "обеспечить согласованность дерева деп" обратно в файловый наблюдатель, такой как npm watch, автоматизировать вводя этот параметр «использовать кеш зависимостей», сделанный пользователем вручную для такой программы, как npm watch ... пусть программа заботится о согласованности, а не о пользователе, и делает это в «реальном времени», в тот момент, когда пользователь сохранил файл, давая гораздо больше времени для scons сделать это дело)

Есть ли в моей идее что-то, что не работает как оптимизация (практически и теоретически), и есть ли у вас другие предложения (которые не должны гарантировать идеальную сборку, если что-то вроде npm watch может позаботиться о вещах, это тоже хорошо )? Подскажите пожалуйста? Спасибо!

Напомним, сценарий использования похож на этот:

1) запустите диспетчер файлов, например npm watch, в исходном каталоге godot
2) пользователь сохраняет / изменяет старый файл
3) npm немедленно запускает scons для этого файла.
4) если компиляция прошла успешно, npm инструктирует scons запустить компоновщик и связать исполняемый файл.

4.1), если дерево депо кэшировано (полная сборка уже была запущена), npm может указать компоновщику просто связать на этом этапе с кэшированной версией дерева депов.
4.1) если кэшированное дерево депов не обнаружено, npm watch запускает полную сборку godot
4.2), если была обнаружена недействительность кеша, например, добавление нового файла, выполните полный обход дерева деплоя (npm не будет использовать опцию «использовать кешированное дерево депозита» с scons).

Надеюсь, это облегчит понимание моей идеи, пожалуйста, дайте мне знать, что с ней не так на данный момент; D

PS Я считаю, что это команда, которая сокращает 15 секунд инкрементальной сборки 35 null с ее "очевидными" последствиями ... Я в основном хочу автоматизировать то, что здесь описано (более или менее, + пусть scons знают, какой именно файл был изменен, если это как-то помогает (или может помочь)):

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

Вот несколько вещей (в произвольном порядке, но я использую числа, потому что

1) По сути, инкрементальные нулевые сборки ничего не значат для любого инструмента, который генерирует файлы ниндзя. У Chrome, AFAIK, есть инкрементная сборка с нулевым значением менее 2 секунд. Это важное замечание, так как падение с 35 секунд до 15 при npm watch по-прежнему очень велико по сравнению с сборкой Ninja на основе мезонов или cmake. Ninja также делает то же самое, что и Scons, поскольку выполняет перестройку в случае изменения командной строки (make, конечно, этого не делает).

2) CMake недавно реализовал возможность использовать CONFIGURE_DEPENDS в качестве аргумента для системы glob. Это всегда было рекомендовано против, потому что такие инструменты, как xcodebuild и msbuild, исторически (и в настоящее время) не поддерживали обнаружение изменения каталога. Это, черт возьми, одна вещь, которую Scons могли бы улучшить, но у меня нет ни времени, ни терпения, чтобы глубоко погрузиться в проект, чтобы реализовать это. По сути, каждая ОС обновляет каталог при изменении его содержимого, будь то добавленный файл, измененный файл или удаленный файл. При внесении инкрементных изменений можно просто проверить, какие каталоги были изменены, и указать только те, которые были проверены при повторной настройке. Это может уменьшить объем выполняемой работы, поскольку вы глобализируете не все дерево целиком, а более мелкие фрагменты. Для небольших проектов это нормально. Будет ли это полезно для Godot или нет, потребует некоторого тестирования, и это большая работа, чтобы проверить, поможет ли это вообще.

3) Хотя приятно видеть, что Scons получает больше внимания, я лично считаю, что для Godot лучше перейти на более используемую систему сборки для сообщества в целом. Я не могу думать о каком-либо большом проекте, использующем Scons, за пределами годота. GNOME / GTK недавно перешел на мезон (без CMake), KDE уже довольно давно используется на CMake. Хотя это неофициальное свидетельство (и, следовательно, базовая предвзятость подтверждения), я знаю нескольких разработчиков на C ++, которые хотели бы попробовать Godot, но предпочли бы больше никогда не трогать scons. Избавиться от неприятных впечатлений и, следовательно, от кислого привкуса, оставшегося во рту разработчиков, сложно, и я искренне желаю проекту Scons всего наилучшего. Но я знаю, что сообщество C ++ в целом уже ненавидит долгое время компиляции. Длинные инкрементные нулевые сборки (или даже длинные инкрементальные сборки из 1 файла) - это кошмар в современном мире.

Я собираюсь попробовать еще раз, но для этого могу настроить таргетинг на CMake. Переход с CMake на meson намного проще, благодаря тому, что у meson есть скрипт преобразования, который может выполнять много работы. CMake может немного упростить обработку зависимостей с новым модулем FetchContent. Посмотрим, как это получится. Скажу, я рад, что эти скрипты кодогенерации были перенесены в отдельные файлы. Использование CMake будет приятным хотя бы потому, что перейти на другой стандарт C ++ так же просто, как target_compile_features(<target> (PUBLIC|PRIVATE|INTERFACE) cxx_std_<number>)

Очевидно, что любые вещи, связанные с системой сборки, будут спорными, но попытка не повредит.

Честно говоря, (и это может показаться бессердечным) у меня нет желания глубоко погружаться в проект Scons, чтобы улучшить его. Может быть, после 2020 года, когда Python 2.7 официально окончательно мертв и проект сможет перейти на Python 3.5+, только его стоит изучить или улучшить, возможно, с помощью асинхронных операций. Однако до тех пор я бы предпочел не трогать его.

Может быть, после 2020 года, когда Python 2.7 официально окончательно мертв, и проект сможет перейти на Python 3.5+, только его стоит изучить или улучшить.

Scons 3 поддерживает Python 3.5+: https://scons.org/tag/releases.html .

Я действительно не понимаю, как можно так не любить Scons и любить беспорядок конфигурации, связанный с CMake, где даже трудно определить свои собственные настройки сборки, если вы пользователь, трудно понять, какие есть параметры, их типы и какие являются внутренними определениями, это только причиняло мне боль, и я действительно был рад, что Годо не использовал их.

В любом случае, если вы чувствуете, что это будет лучшее решение, продолжайте и попробуйте, я могу в конечном итоге изменить свое мнение о CMake.

где даже сложно определить свои собственные настройки сборки, если вы пользователь,

Если это будет задано, значит, CMake используется неправильно. Все настройки инструментальной цепочки должны быть в файле инструментальной цепочки, а любые конфигурации для конкретного проекта передаются через флаги (или графический интерфейс, или редактировать файл кеша, или что-то еще). Все задокументировано и типизировано, даже авторы проекта могут хорошо задокументировать и ввести свою выставленную конфигурацию. Вы должны прочитать CGold и современные стандарты CMake.

@Faless никто не отрицает, что язык CMake ужасен. Но реализация лучшая в своем классе. Я рассматривал возможность написания транспилятора с лучшего языка, чтобы решить эту проблему.

@ OvermindDL1 нравится предложение прочитать CGold.

Если это будет задано, значит, CMake используется неправильно.

Что ж, я думаю, что все программы, с которыми я столкнулся, тогда делали это неправильно.

Честно говоря, я ненавижу менять флаги с помощью -DI_LOVE_CMAKE_AND_MAKE_DEFINES_LONG=on (правда? on ?). Не говоря уже об идее редактирования файла кеша О_о. Или что, если я хочу изменить флаг, мне в конечном итоге придется удалить папку сборки и начать с нуля (потому что, знаете ли, кеш отличается!) ... так много для инкрементальных сборок ...

РЕДАКТИРОВАТЬ: Кроме того, одна вещь, которая мне очень понравилась в Scons (по крайней мере, в Godot, и это может быть возможно с другой системой сборки, конечно), заключается в том, что я на самом деле не читал никаких стандартов или документов, я просто запускаю scons -h в папке Годо

95% файлов сборки, которые я видел на GitHub, ошибочны. Людям лень строить системы и следовать практикам культа карго, чтобы что-то сколотить.

@isaachier , просто в качестве метрики, не могли бы вы привести 2 примера плохого и хорошего файла CMake? Как бы вы это подумали :

Лучше, чем большинство из тех, что я видел. Тем не менее, если вы не используете CMake> = 3.0, то ваш опыт работы не с современным CMake.

Что ж, я думаю, что все программы, с которыми я столкнулся, тогда делали это неправильно.

Я склонен видеть, что сейчас это делается хорошо.

Честно говоря, я ненавижу менять флаги через -DI_LOVE_CMAKE_AND_MAKE_DEFINES_LONG = on (действительно? На?). Не говоря уже об идее редактирования файла кеша О_о. Или что, если я хочу изменить флаг, мне в конечном итоге придется удалить папку сборки и начать с нуля (потому что, знаете ли, кеш отличается!) ... так много для инкрементальных сборок ...

Вам не обязательно использовать on , вы можете использовать true , 1 и множество других вещей. Это сделано для того, чтобы вы могли выбрать подходящее логическое имя, которое хорошо сочетается с именем флага.

И вам никогда не придется перестраивать папку сборки, если вы меняете параметры, cmake исключительно хорош при перестройке, когда это необходимо.

Тем не менее, все, кто касается систем сборки C / C ++, должны прочитать CGold, а также официальное руководство по CMake. Это очень простое в использовании CMake права, часто гораздо короче , а также. Не следует использовать древние методологии CMake2. На самом деле, любой, кто зависит от версии CMake 2.x, делает что-то абсолютно неправильно (неправильно использует цели и цепочки инструментов, неправильно устанавливает параметры и т. Д. И т. Д.).

Спасибо за объяснения, хотя я остаюсь скептически настроенным, я с нетерпением жду возможности увидеть, как это сработает для Годо :).

@ slurps-mad-rips Ваш пост с предполагаемым примером кода CMake для включения режима C ++ 11 является полностью нестандартным CMake по ряду причин, включая, помимо прочего:

• Установка неэкспонированных переменных.
• Аргументы Toolchain устанавливаются в файле, отличном от toolchain.
• Совершенно не так, как вы делаете что-то вроде включения режима 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)

И это будет гарантировать, что используемая инструментальная цепочка знает, что ей нужно установить этот режим (и вы можете указать, как обрабатывать сбои, если используете компилятор, который также не поддерживает его). Предполагая, что специальные флаги командной строки, специфичные для компилятора, в файле сборки являются чрезвычайно плохой формой, поскольку они должны существовать только в файлах инструментальной цепочки, и тот факт, что пример мезона, показанный в предыдущем сообщении, фактически указывает конкретные аргументы, по существу означает, что вы жестко кодируете поддерживаемые компиляторы.

Учитывая, что существует предварительно созданный файл CMake Toolchain практически для любой инструментальной цепочки, о которой вы можете подумать (включая все стандарты MSVC различных разновидностей, GCC / Clang, android, iOS, emscripten и т. Д. И т. Д.), Вы не следует изобретать колесо заново. Если пользователь, который компилирует что-то вроде godot, хочет использовать свой собственный компилятор с уникальными аргументами командной строки (например, компилятор Intel или, возможно, какой-то выделенный чип или просто простой RPi), то скрипту сборки не нужно заботиться об этом или вообще нужны какие-либо изменения (код, конечно, может, но в оптимальном случае никогда не должен, поскольку CMake может сообщить ему, что все поддерживается через определения), и пользователь может предоставить свой собственный файл инструментальной цепочки для сборки для использования.

РЕДАКТИРОВАТЬ: И никогда не сбрасывайте со счетов широкую поддержку. Я не могу найти ничего о том, что meson может создавать файлы проекта для KDevelop (IDE, которую я использую, которая, что интересно, использует CMake в качестве формата сборки, я иногда использую CLion на работе, она также использует CMake), где почти все IDE выходят ( даже Visual Studio!) теперь может открывать проекты CMake изначально (в дополнение к тому, что CMake может напрямую создавать проекты для большинства IDE, если вы того пожелаете).

@ OvermindDL1

Это совсем не нестандартный CMake. Пример кода предназначен для CMake 3.0, версии, в которой CXX_STANDARD не существует. Отсюда легко видно, что вы используете target_compile_features с cxx_std_ и номером стандарта. Это новый и современный способ cmake установить стандартную версию. set_target_properties - это более старый подход для каждой цели.
Фактически, точный код, взятый из документации CMake, таков:

target_compile_features(mylib PUBLIC cxx_std_11)

Однако CXX_STANDARD не устанавливает поддержку libc ++ для clang, поскольку clang использует libstdc ++ по умолчанию в linux, если он не настроен (и он никогда не настраивается для использования libc ++ по умолчанию в большинстве дистрибутивов Linux, так как это может вызвать ошибки компоновщика и проблемы с ABI) . Единственный способ сделать это сейчас - проверить, поддерживает ли компилятор -stdlib=libc++ и передать его компилятору через выражение генератора. В этом нет ничего, связанного с неэкспонированными переменными.

Кроме того, мне не нравится, что вы оставляете комментарий, чтобы внести исправления в комментарий, который я сделал несколько месяцев назад, особенно с учетом того, что в следующей попытке я буду нацеливаться на CMake вместо Meson. Это бестактно и, на мой взгляд, ничего не добавляет к разговору.

CMake 3.0 достаточно стар, чтобы больше не поддерживаться (10 июня 2014 г.). В настоящее время никто не должен запускать что-либо меньшее, чем CMake 3.10, хотя в настоящее время предпочтительнее оставаться в курсе последних событий с помощью CMake 3.12.

И да, приведенный вами пример категорически не рекомендуется (я думаю, даже CGold упоминает, что этого не делает).

И да, я имел в виду target_compile_features. ^. ^;

Однако CXX_STANDARD не устанавливает поддержку libc ++ для clang, поскольку clang использует libstdc ++ по умолчанию в linux, если он не настроен (и он никогда не настраивается для использования libc ++ по умолчанию в большинстве дистрибутивов Linux, поскольку это может вызвать ошибки компоновщика и проблемы с ABI). Единственный способ сделать это на данный момент - проверить, поддерживает ли компилятор -stdlib = libc ++, и передать его компилятору через выражение генератора. В этом нет ничего, связанного с неэкспонированными переменными.

Все текущие инструментальные цепочки отлично справляются с этим для clang, по крайней мере, с C ++ 14, поскольку это то, с чем я компилирую (и пару C ++ 17).

Кроме того, мне не нравится, что вы оставляете комментарий, чтобы внести исправления в комментарий, который я сделал несколько месяцев назад, особенно с учетом того, что в следующей попытке я буду нацеливаться на CMake вместо Meson. Это бестактно и, на мой взгляд, ничего не добавляет к разговору.

Извиняюсь, не заметил дату , когда я читал накопившихся (и есть много накопившихся здесь). Я только что заметил кое-что, что казалось ужасно неправильным для любых современных предложений из того, что я видел в течение нескольких лет, и не видел никаких исправлений в сообщениях вскоре после того, как хотел, чтобы неверная информация не распространялась. :-)

Единственный способ сделать это на данный момент - проверить, поддерживает ли компилятор -stdlib = libc ++, и передать его компилятору через выражение генератора.

Однако да, это работа файла ToolChain, которые должны абсолютно никогда не появляются в файле сборки, когда -

В этом нет ничего, связанного с неэкспонированными переменными.

Я просто ссылался на переменные, которые устанавливаются, а затем используются в других местах только в отдельных местах, что, в частности, не рекомендуется в CGold по ряду причин.

CMake 3.0 достаточно стар, чтобы больше не поддерживаться (10 июня 2014 г.). В настоящее время никто не должен запускать что-либо меньшее, чем CMake 3.10, хотя в настоящее время предпочтительнее оставаться в курсе последних событий с помощью CMake 3.12.

Они не должны, но в некоторых местах есть. Для игрового движка, который пытается идти в ногу со временем и использует новейшие технологии, можно использовать последнюю версию CMake. Однако мне более чем хорошо известны чрезвычайно активные проекты, застрявшие в более старых версиях, таких как 3.5 и в некоторых случаях 3.4. Фактически, некоторые хорошо известные библиотеки C по-прежнему нацелены на CMake 2.8 (см. SDL2, libssh2, libgit2 и т. Д.). Конечно, это огромная головная боль.

Однако да, это задача файла инструментальной цепочки, который ни в коем случае не должен появляться в файле сборки.

Такое предположение (что файлы инструментальной цепочки хорошо написаны и охватывают все возможные системы и все версии CMake) вызывает проблемы в текущей общей экосистеме C ++. При использовании clang библиотека должна обеспечивать возможность компиляции для libstdc ++ или libc ++ (особенно при использовании через вызов FetchContent ). CheckIncludeCXX и CheckCXXCompileFlag по-прежнему необходимы даже для некоторых флагов, которые не существуют в GCC, но существуют в Clang (и наоборот). Основная проблема здесь в том, что интерфейсы компиляторов сильно разошлись, и вместо того, чтобы продавцы тратить время на упрощение вариантов совместимости или даже обсуждение общего интерфейса, такое поведение возлагается на нас, разработчика, когда все, что мы хотим сделать, это написать код. Поверьте мне, никто на этой планете не обеспокоен состоянием систем сборки C и C ++ и управлением зависимостями больше, чем я, но необходим прагматизм в отношении существующих библиотек на CMake. Хорошая вещь в переходе от системы сборки к CMake заключается в том, что мы можем начать с самых последних и лучших функций. Проблема заключается в стагнации системы сборки, потому что никто не хочет ее трогать (за исключением той храброй души, которая выделила сценарии сборки генерации кода в отдельные сценарии), но потребуется некоторая работа, чтобы убедиться, что она не выйдет из-под контроля. (что будет, потому что ... я имею в виду, что это система сборки. Они всегда так делают)

Я, должно быть, единственный парень, которому действительно нравится писать сценарии сборки, особенно в CMake;).

Такое предположение (что файлы инструментальной цепочки хорошо написаны и охватывают все возможные системы и все версии CMake) вызывает проблемы в текущей общей экосистеме C ++. При использовании clang библиотека должна обеспечивать возможность компиляции для libstdc ++ или libc ++ (особенно при использовании через вызов FetchContent).

Такие вещи должны быть свойствами, передаваемыми в цепочку инструментов, чтобы цепочка инструментов затем могла действовать.

Кроме того, если у вас очень уникальная настройка, вполне разумно включить файлы инструментальной цепочки, например, для очень нестандартной сборки Android или около того (хотя расширенный набор инструментальных цепочек cmake охватил почти все, что мне было нужно до сих пор).

Проблема заключается в стагнации системы сборки, потому что никто не хочет ее трогать (за исключением той храброй души, которая выделила сценарии сборки генерации кода в отдельные сценарии), но потребуется некоторая работа, чтобы убедиться, что она не выйдет из-под контроля. (что будет, потому что ... я имею в виду, что это система сборки. Они всегда так делают)

На самом деле это отличный момент для выбора CMake сейчас, у него есть четко определенный набор стандартов, которым нужно следовать, и они действительно хорошо работают сейчас, после более чем десятилетнего предыдущего опыта, как хорошего, так и плохого.

Я, должно быть, единственный парень, которому действительно нравится писать сценарии сборки, особенно в CMake;).

Мне это точно нравится по сравнению с альтернативами, хотя я писал в нем достаточно долго, чтобы он имел смысл для меня, хотя это определенно не означает, что это будет для всех. ^. ^;

За эти годы я использовал много разных систем сборки. В последнее время мне больше всего понравился CMake, но я определенно вижу привлекательность SCons и то, насколько он гибкий.

Даже если SCons не идеален (что такое система сборки?), Он может быть достаточно хорош.

• Предоставляет ли он необходимые функции?
• Сколько накладных расходов это создает?

Если SCons набрал «достаточно хорошо» для обоих баллов, оставьте его.

Кто-нибудь из вас, предлагая заменить SCons чем-то другим, действительно приложил усилия, чтобы узнать, как работает система сборки Godot?

Подсказка: это невероятно сложно, и я не думаю, что существует много (или каких-либо) проектов, использующих сборку CMake для такого количества платформ и позволяющих одновременно настраивать / компилировать несколько целей сборки, как это делаем мы.

Все усилия тех, кто сказал: «Я перенесу систему сборки Godot на что-нибудь еще», пока что потерпели неудачу, когда осознали всю сложность того, о чем заботится SCons.

На мой взгляд, это лучший инструмент для работы. Ничего подобного нет. Если вы, ребята, жалуетесь на базовое время компиляции (которое составляет всего 4/5 секунды на системе среднего и высокого уровня с SSD), вам действительно стоит сначала попытаться понять все, что Godot делает при сборке, и посмотреть, как это будет работать в CMake или чем-то еще. .

Я посмотрел. Я не уверен, что это можно отменить в CMake или где-либо еще. Но я тоже ленивый;). Посмотрим, что будет.

Как тот, кто делал портвейн из базеля. Я смог добраться до того, что редактор Godot запускался без значков.

Я почти уверен, что CMake сможет достичь этого.

PS. Ближайший проект-конкурент с большим количеством платформ - Urho3d.

Я воспроизвел свой результат bazel на cmake.

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
• Visual Script и GDscript работают

@fire Спасибо за это. Я вижу много возможностей для улучшения, которые упростили бы обслуживание этих файлов CMake (и время, потраченное на добавление новых функций или флагов компилятора). Тем не менее, я могу заняться этим в следующие выходные, график еще не определен.

Потрясающая работа @fire. Рад видеть, что кто-то здесь может производить что-то не только в одной системе сборки: smile :.

Небольшое обновление. Сегодня у меня было немного времени, чтобы заняться строительством на основе работы @fire . К сожалению, сценарии генерации кода все еще слишком встроены в текущую систему Scons, и для их полного извлечения требуется некоторая работа (это, конечно, при условии, что я правильно читаю код). Тем не менее, это, вероятно, будет отдельная проблема + запрос на перенос. Я определил несколько областей, где можно использовать внешний файл шаблона (или серию файлов шаблонов). Python поддерживает строки шаблона, и это может немного облегчить жизнь, вместо того, чтобы обрабатывать строки, добавлять их в список, а затем обрабатывать больше строк и добавлять их в список и т. Д. И т. Д.

В идеале скрипты генерации кода должны иметь возможность запускаться, как если бы они были исполняемыми файлами, без знания сборки. Пока им были переданы нужные файлы, мы могли бы полностью перейти на любую другую систему сборки.

@ slurps-mad-rips Извлечение этого из вашей системы SCons - хорошая идея даже в SCons. Вы можете повесить GIL из-за слишком большого количества логики в процессе и снизить производительность сборки. Иногда это приводит к некоторым условиям гонки закрытия / открытия файла при параллельном построении (хотя часто разрешается путем открытия файла в контексте).

Всем здравствуйте,

Я собираюсь использовать это пространство, чтобы держать людей в курсе переноса на CMake. Если потребуется, я сделаю отдельную проблему и буду отслеживать изменения там, хотя это хорошая область, учитывая, что у нее огромное отставание в обсуждениях, и я думаю, что было бы напрасно терять так много контекста.

Я отвлекся. Я собираюсь сделать перерыв в переносе CMake на следующую неделю, пока я буду присутствовать на конференции, однако вы можете увидеть усилия моей первоначальной попытки переноса здесь . Пожалуйста, имейте в виду, что я буду снимать, чтобы оставаться 1: 1 с текущей основной веткой, и поэтому я буду принудительно продвигать изменения по мере их поступления, чтобы я мог сохранить перебазирование. По мере приближения к стабильности я отправляю запрос на перенос, чтобы упростить работу с ребазами, а также чтобы было проще комментировать изменения или задавать вопросы. Я думаю, что этот перенос на CMake не только выполним, но, по крайней мере, он сделает еще одного человека (меня) хорошо разбирающимся в том, как на самом деле построен и сконструирован Godot, и я мог бы выразить это словами, чтобы другие могли получить система сборки с высоты птичьего полета. Этот порт также может облегчить рабочий процесс каждого в долгосрочной перспективе, особенно с выпусками. Я не собираюсь лгать, смешивание файлов CONFIGURE_DEPENDS с Ninja на самом деле довольно приятно.

И последнее: я настоятельно рекомендую вам всем взглянуть на вспомогательные модули CMake, которые я написал, потому что, если вы пишете другой проект CMake, эти модули могут пригодиться.

Удалось ли вам обновиться до последней версии 3.1 альфа? Альфа может быть хорошей целью. В настоящее время пробую сборку.

Заголовок этого выпуска: Подумайте о переносе системы сборки на Meson . Я считаю, что здесь неуместно обсуждать CMake. Обсуждение CMake должно иметь отдельную тему. Сравнение Meson с чем-либо еще в порядке.

@zaniar В этой теме было много дискуссий о системах сборки в целом. Тот факт, что заголовок не был обновлен, не означает, что мы собираемся внезапно создать новую проблему, потерять весь контекст для обсуждения и начать все сначала. Я считаю неуместным просить нас внезапно отказаться от нескольких месяцев дискуссий.

@fire Последние несколько недель я был занят работой, у меня большой дедлайн на пятницу, а потом, возможно, у меня будет время обновить вилку. У меня есть несколько изменений на месте. Я забыл отжиматься, но сейчас у меня нет времени. (Между этим портом системы сборки, моей вилкой gnu m4, 15 предложениями, которые я пишу для встречи по стандартам C ++ в Сан-Диего и CppCon в последнюю неделю месяца, я абсолютно завален, и мне некого винить, но себя)

Да, исходной целью обсуждения был Meson, но я думаю, что это естественно, что с тех пор были подняты и обсуждены другие системы сборки, и, вероятно, имеет смысл держать обсуждение в рамках этого вопроса здесь, а не распространять его, например @slurps - сказал безумный рипс.

Я согласен с переходом на CMake. Он имеет большую поддержку с его наборами инструментов. Например, сборки Android становятся очень простыми по сравнению с тем, что Godot делает в своем файле SCsub, который мне кажется «неподдерживаемым».

Как проект с открытым исходным кодом, Godot должен предлагать решения, которые легко поддерживать и которые участники с большей вероятностью будут знать и иметь возможность внести свой вклад.

Кроме того, я думаю, что это важно для внедрения GDNative. Какой бы инструмент сборки ни использовался, должен быть пример или стандартный проект с легко изменяемым скриптом сборки, который поддерживает сборку для всех платформ, включая iOS, Android и т. Д.

Также нормальные модули должны быть скомпилированы как разделяемые библиотеки. Это связано с # 19486, так что движок можно разделить на несколько загружаемых компонентов.

Я действительно занимаюсь этим. Я давно не продвигал свои изменения, потому что был занят CppCon, предстоящим совещанием по стандартам C ++, а на следующей неделе мы готовим релиз. Достаточно сказать, что у меня не было много времени, чтобы закончить порт, но большую часть моего времени я собираюсь потратить на копирование скриптов Python, которые генерируют код C ++ в будущем. Я надеюсь возобновить работу над своим портом в эти выходные. В настоящее время я оцениваю, следует ли автоматически приобретать сторонние зависимости и применять исправления, хранящиеся в репо, или нет. Один вопрос, который у меня есть к основным разработчикам, заключается в том, насколько они открыты для взлома всех сторонних репозиториев из основного репозитория в их собственные репозитории в организации. Я довольно сильно полагаюсь на FetchContent в своих собственных проектах, и в настоящее время мне жаль, что я не могу сделать это для этих сторонних зависимостей, которые были слегка разветвлены. Это также позволило бы мне работать над каждым из них по очереди, чтобы очистить их файлы cmake, а также вносить инкрементные изменения в основное репозиторий после того, как каждая сторонняя библиотека будет перенесена.

Кроме того следует отметить, что я пытаюсь также модуляризую сам двигатель, так что эти компоненты технически могут быть обновлены отдельно друг от друга , если кто - то хотели. Это может решить проблему, о которой упоминал

Наконец, я добавляю поддержку нескольких дополнительных инструментов сборки для основных разработчиков, если они есть в системе. Такие вещи, как clang-format, clang-tidy, ccache или sccache, distcc, clang-check, address sanitizer, ubsanitizer, thread sanitizer и т.д. я обнаружил), но их будет необязательно включать. По крайней мере, использование sccache или ccache даст некоторое улучшение сборки при переключении между сборками и наоборот. Было бы неплохо дождаться выхода CMake 3.13, так как это решит некоторые проблемы, на которые мне приходилось полагаться, но важно то, что я настраиваю его так, чтобы текущий рабочий процесс "начала работы" был чтобы по-прежнему запускать pip install через Python 3.5 или новее, однако он будет внутри virtualenv, поэтому людям не придется вмешиваться в среду своей системы. (Это также позволило бы другим поэкспериментировать с использованием дополнительных библиотек Python в качестве зависимостей для различных сценариев генерации кода и не помнить об их удалении позже)

В любом случае, извините за внезапное обновление информации, вы все. Я посвятил себя завершению этого порта, но в последнее время жизнь помешала 😅

Я довольно сильно полагаюсь на FetchContent в своих собственных проектах, и в настоящее время мне жаль, что я не могу сделать это для этих сторонних зависимостей, которые были слегка разветвлены.

Вы также можете использовать Hunter и создать репозиторий кода, специфичный для Godot (специальный репозиторий git, например, на github) и получить доступ ко всем зависимостям таким образом, поскольку он обрабатывает строительство, кеширование и т. Д. По мере необходимости и должным образом (или отправьте все зависимости в «основной» репозиторий пакета 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 - легкий ветерок для изучения)

Плюсы Meson

• много полезных целей по умолчанию: дезинфицирующие средства, сборки unity бесплатно, предварительно скомпилированные заголовки бесплатно, покрытие бесплатно ...
• документация надрывает задницу документации CMake: http://mesonbuild.com/
• Я обнаружил, что кросс-компиляция намного проще
• У Meson есть очевидный способ делать все

Что бы я выбрал? Я бы выбрал Meson, если кросс-компиляция будет интенсивной, и вы заботитесь о быстром времени компиляции (по умолчанию поддерживаются единые сборки и предварительно скомпилированные заголовки).
Я бы подумал о CMake, так как это стандарт, и его вклад, возможно, важен для команды. Я бы лично выбрал Meson, но это только личное мнение, так как я считаю этот инструмент лучше, и это экономит мое время (сценарии CMake, обработка пространства, выражения генератора и т. Д. Я смотрю на вас).

Извините за эту бесстыдную саморекламу ниже, но я думаю, что контекст умоляет об этом.

Если кому-то интересно, у меня есть небольшая серия статей о более или менее базовом Meson (4 статьи):

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

У меня есть (немного устаревший) ответ по системам сборки в StackOverflow:

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

Всего два цента :)

@germandiago Это отличная рецензия - я замечательно, если бы я мог работать с godot + CLion, который, к сожалению, только CMake.

Да, большинство современных IDE - это либо CMake-only, и / или некоторая пользовательская система сборки, и / или «необработанные вызовы», которые теряют множество функций. CMake действительно стал стандартом, заслуживает того или нет.

@dorkbox, если я смогу получить эти изменения, над которыми я работаю, вы определенно сможете работать в рабочем процессе CLion (cmake + ninja).

@germandiago

Я на самом деле теперь друзья (более или менее 😛), с автором мезона как из CppCon 2018. Мы оба оказались на одной и той же бумаги на предстоящей встрече в отношении модулей под названием «Помните Fortran», и я буду представлять его доклад на указанной встрече (на самом деле это на следующей неделе!), и мы также были на той же панели систем сборки на CppCon.

Я бы с удовольствием использовал Meson. Если вы прочитаете дальше в ветке, я пробовал мезонный порт, но в то время все было слишком интегрировано с Scons. Я все еще вытаскиваю текущие сценарии генерации кода, чтобы они были отдельными «исполняемыми» сценариями, так что, если в будущем переход на Meson не исключен. Однако это медленная работа, и я написал несколько шаблонов jinja, чтобы помочь с генерацией кода, чтобы scons можно было полностью отбросить. Тем не менее, хотя мой публичный форк устарел, тот, который у меня есть дома, немного впереди (и синхронизирован с приватным форком). К сожалению, работа мешает, и Сан-Диего, к сожалению, будет «красть» больше моего времени. После этого, однако, я должен быть свободен, чтобы удалить некоторые из локальных экспериментов, которые у меня есть на моей частной вилке, и, наконец, вернуться к поезду godot cmake. Я стремлюсь обеспечить выполнение полного запроса на вытягивание без серьезных сбоев в текущем рабочем процессе.

(Как в стороне: спасибо всем за терпение , которое вы имели в то время как я работаю на этом я знаю , что это был некоторое время , так как я начал, но я представляю мой работодатель в США Национального органа по C ++ комитет стандартов теперь так мое расписание. был немного более полным в последнее время, особенно когда мы затронули важные темы, такие как модули, сопрограммы и диапазоны)

Да, большинство современных IDE - это либо CMake-only, и / или некоторая пользовательская система сборки, и / или «необработанные вызовы», которые теряют множество функций. CMake действительно стал стандартом, заслуживает того или нет.

Возможный полезный инструмент для использования мезонов с IDE:

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

Это заставляет среду IDE думать, что она использует CMake, но на самом деле использует мезон под капотом.

Немного предыстории: я был большим сторонником CMake в течение многих (10?) Лет, но в прошлом году или около того влюбился в meson. Похоже, что Meson написан с целью использования полезных функций CMake при исправлении / предотвращении многих неудобств CMake. Единственное препятствие, с которым я сейчас сталкиваюсь при внедрении мезона в проект, - это поддержка 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

Докажи, что редукция неверна @ slurps-mad-rips :).

800-фунтовая горилла в комнате, о которой еще не упоминалось. Одна из претензий Godot к славе - кроссплатформенная совместимость. Из этого следует, что любая система сборки, на которую возможен переход, должна быть доступна и протестирована на всех платформах, на которые нацелена Godot. Тот, кто стоит за такой миграцией, должен быть склонен протестировать миграцию на всех поддерживаемых платформах или, по крайней мере, быть частью команды, которая это делает. В противном случае я бы посчитал такой шаг противоречащим философии Годо и вообще плохой идеей.

@lazybullfrog У меня есть доступ примерно к 5 отдельным машинам для настольных компьютеров и нескольким мобильным устройствам. Часть моего переноса на cmake заключается в том, чтобы убедиться, что для всех текущих платформ доступны инструменты cmake.

@ slurps-mad-rips Это один из тех хайку? Если нет, я готов помочь с тестом. Спасибо.

Часть моего переноса на cmake заключается в том, чтобы убедиться, что для всех текущих платформ доступны инструменты cmake.

Не забывайте также, что если вам нужны инструменты cmake для платформы, то, вероятно, есть готовый на https://github.com/ruslo/polly, и если его нет, вам следует PR его. :-)

@ slurps-mad-rips Как дела? Я заметил, что вы обновили код 14 января. Я пробовал компилировать в Windows, но не нашел pkgconfig.

@fire life решила бросить мне несколько хитростей, и мне пришлось о них позаботиться. К сожалению, личные вещи. Я сосредоточился на работе и доработал библиотеку IXM, которую я использую, чтобы уменьшить объем работы, которая будет скопирована в godot. К счастью, я беру отпуск через неделю (я направляюсь в Кону на встречу WG21 ISO в этом квартале в эти выходные), так что у меня будет немного свободного времени, чтобы поработать над этим, и (надеюсь!) У меня будет рабочая сборка для macOS, Linux и Windows в ближайшее время ™. Android и iOS, за которыми следуют FreeBSD и Haiku (извините, @lazybullfrog , хотя вы можете тестировать пораньше / чаще) будут моим следующим приоритетом после этого.

Самая большая часть работы / блокировщика до сих пор заключалась в извлечении скриптов Python в «устанавливаемые» инструменты, которые были отделены от Scon и выполнялись как процессы. Фактическое получение зависимостей, настроек и т. Д. Было проще по сравнению.

@ slurps-mad-rips, жизнь тоже бросила мне несколько кривых шаров. Возможно, нам стоит создать бейсбольную команду. 😂

К счастью, с тех пор, как я в последний раз комментировал, одним из тех кривых шаров был 8-ядерный Xeon с 32 ГБ оперативной памяти с установленными Haiku и FreeBSD. Возможно, скоро у меня будет время, чтобы помочь проверить и то, и другое.

Я в восторге от того, что обе эти платформы привлекают внимание. Жду скорого тестирования.

Я считаю разумным иметь несколько систем сборки. Возможно, это официальная система сборки, которая хорошо поддерживается, а другие предоставляются на основе принципа «вы разберетесь». Пользователи все равно захотят использовать свою собственную систему сборки, так почему бы не объединить свою работу в одном месте?

Я был бы готов внести свой вклад в порт Базель, если все пойдет по такому пути.

Я считаю разумным иметь несколько систем сборки. Возможно, это официальная система сборки, которая хорошо поддерживается, а другие предоставляются на основе принципа «вы разберетесь». Пользователи все равно захотят использовать свою собственную систему сборки, так почему бы не объединить свою работу в одном месте?

Как упаковщик Linux, я видел сотни проектов с различными системами сборки. Я видел несколько, у которых было несколько доступных систем сборки. Я никогда не видел ни одной, где бы не было полного беспорядка, особенно когда альтернативные системы сборки были внесены впервые участниками «пожалуйста, добавьте CMake, это так круто», которые затем исчезли из проекта, и сопровождающие не удосужились обновить его.

Там нет никакой ценности в поддержке нескольких buildsystems, и я не буду сливать любой PR идет в этом направлении. Я один из основных разработчиков buildysytem, ​​и я определенно не хочу брать на себя бремя поддержки альтернативных, когда нам нужно что-то изменить.

В настоящее время у нас есть система сборки, которая работает для всех и хорошо поддерживается, и мы не собираемся менять ее. Если кто-то действительно хочет изучить другие варианты, не стесняйтесь, и если конечный результат также работает для всех, может быть хорошо поддержан и обеспечивает добавленную стоимость без больших недостатков, мы рассмотрим это.

Если кто-то действительно_ хочет изучить другие варианты, не стесняйтесь, и если конечный результат также работает для всех, может быть хорошо поддержан и обеспечивает добавленную стоимость без больших недостатков, мы рассмотрим это.

Вот что я делал со своим портом CMake. В настоящее время на моем текущем компьютере (с 64 ГБ ОЗУ, сопоставимым процессором и т. Д.) Безоперационная смена или изменение одного файла под scons занимает более 10 секунд. сборка завершается менее чем за 0,2 секунды в безоперационной сборке (в Windows, где запуск процесса стоит дорого). Я также могу использовать инструмент sccache из mozilla, если он установлен, и это было чрезвычайно полезно для редактирования частей кодогенератора / запуска регенерированной сборки с нуля, чтобы убедиться, что ничто не зависит от моей локальной среды.

большая часть моего времени была потрачена на извлечение сценариев генерации кода в сценарии Python, которые могли работать сами по себе. Если бы это было единственное, что было объединено в Годот, мое время, потраченное на это, не было бы пустой тратой. Он также решает проблему run_in_subprocess , существующую в настоящее время для решения проблем с Windows с распараллеливанием.

Я только что вернулся из поездки и смог немного поработать. Прямо сейчас мне все еще нужно скопировать несколько файлов из ручного запуска scons, но со временем я убираю сгенерированные источники. Заголовки license.gen.h и method_bind.inc в настоящее время являются моей самой большой целью, но мне нужно несколько дней, чтобы разобраться с джетлагом + работой, прежде чем я займусь ими.

(также просто собираюсь cc @fire, так как он немного интересовался этим прогрессом)

По моему опыту, Meson полностью испорчен при сборке Android на Windows, я просто не могу заставить его работать, чтобы скомпилировать одну из сторонних библиотек, которая его использует (libepoxy). И я думаю, что это слишком сильно привязано к конкретному компилятору.

Все, что мне нужно, - это система сборки, которая может генерировать файлы проекта и файлы базы данных отдельно от команды сборки.

Каждый раз, когда я проверяю новую ветку с серьезными изменениями в файлах, мне приходится запускать Scons из командной строки, чтобы регенерировать мои файлы vsproj, что в любом случае вызывает полную сборку. В Scons, судя по тому, что я видел, нет никакой стадии генерации проекта. По этой же причине он не поддерживает создание баз данных компиляции из коробки для использования в clang-tools.

В настоящее время единственным жизнеспособным решением для кодирования Godot в Windows (с точки зрения IDE) является Visual Studio, в противном случае будьте готовы просто использовать текстовый редактор.

Scons прекрасен и все такое, но когда у меня есть 12-ядерный threadripper и 128 ГБ оперативной памяти, и мне приходится ждать 12+ секунд в Windows, чтобы скомпилировать изменение одной строки (большая часть этого - мышление 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 есть потенциал для компиляции еще быстрее, и я бы сам заменил систему сборки, но у меня нет опыта, поэтому я буквально не знаю, что делать

@Nosliwnayr
можем ли мы избежать предварительно скомпилированных заголовков? я думаю, что это полная чушь, просто будь проще

они также делают совместные проекты, что намного раздражает, и это просто бесконечное раздувание, со слишком большим количеством недостатков в моей голове - но эй, если кто-то использовал их эффективно, я крут, но мне они кажутся грязным трюком, вместо этого настоящей оптимизации, а я не люблю дешевые уловки, если честно

после использования нереального движка 4 я устал от предварительно скомпилированной ерунды объемом 20 ГБ, я просто не думаю, что они того стоят, должна быть менее глупая система (нереальный движок 4, потреблял до 60 - 80 гб для меня не круто)

если Годо пойдет в этом направлении, я предполагаю, что разработчики потеряли свои чертовы умы

черт возьми, я бы предпочел, чтобы они придерживались scons, если он избегает шара безумия unreal Engine 4, я думаю, что более разумным подходом было бы улучшить scons, вместо того, чтобы полностью заменять его, с совершенно новой сломанной задницей система компиляции, когда работает текущая ... более или менее

Я думаю, что умственные усилия, необходимые для того, чтобы внедрить новую систему, намного выше, чем просто улучшение того, что у нас уже есть, и новый компилятор может в конечном итоге на несколько месяцев функционально сломаться.

я уверен, черт возьми, я не собираюсь жаловаться, если это будет сделано, но с таким критическим компонентом двигателя вам в значительной степени придется пойти ва-банк, после того, как это изменится, пути назад не будет

@ RaTcHeT302 -

В самом деле, если бы все люди, жалующиеся на проблемы с SCons, помогли бы их исправить, а не предлагали бы переключить сложную систему сборки на другую, более новую, более блестящую ... ну, многие из таких проблем были бы исправлены ..

@bdbaddog Scons не создает файлы сборки промежуточного этапа. Он выполняет этап «зависимости проекта» на том же этапе, что и компиляция, и они не могут быть разделены.

Это все равно, что приказать CMake генерировать файлы проекта каждый раз перед тем, как вы нажмете на свой инструмент сборки, будь то MSVC, ninja-build, make, llvm, выберите свой яд.

Если я переключу ветки git, я не смогу обновить Visual Studio, не выполнив сборку командной строки scons для восстановления правильных файлов .vsproj и .sln - и я почти всегда очищаю изменения веток сборки, поскольку в прошлом у меня возникали проблемы.

Эти промежуточные файлы предназначены не только для сборки, они также могут использоваться статическими анализаторами и другими проектами.

Хотя я согласен с тем, что cmake не идеален (мне он сам не нравится), и я бы предпочел гибкость python, cmake имеет лучшую интеграцию и поддержку всех инструментов сборки на столе.

При преобразовании моей вилки в CMake большая часть сложности заключалась в файлах генерации кода. Представление о сложной конструкции - заблуждение. Сборка не требует бра, потому что она сложная. Это сложно, потому что здесь используются бра.

С учетом сказанного, причина, по которой я остановил работу, заключается в том, что я встретился с ведущими разработчиками на GDC в 2019 году (на встрече GitHub), и они сказали, что абсолютно не намерены переходить на что-то более удобное, сославшись на то, что они предпочли бы это сделать. сборка полностью на Linux, и, судя по тому, что я видел, они нарушают лицензионное соглашение, которое Apple требует принятия для установки инструментов сборки для кросс-компиляции.

Менталитет тех, кто отвечает, очень похож на то, что «цель оправдывает средства», и, похоже, нет никакой заботы о том, чтобы рассматривать сборку как программное обеспечение, и вместо этого Godot рассматривает ее как серию скриптов, которые создают сборку.

Я не буду вносить изменения, которые я внес в генерацию кода для Godot (несмотря на то, что он стал более читаемым и быстрым), и я полностью отказался от этого движка и продолжил свою жизнь. Я намного счастливее, если честно. У движка уже есть значительный технический долг, и я вижу, что это проблема примерно через 3 года, особенно когда комитет по стандартизации C ++ работает над техническим отчетом по инструментам (я участвую в этом и настаивал на стандартизации таких вещей, как файлы опций. в некоторой степени, но это всего лишь технический отчет, поэтому некоторые люди отклонятся от него).

Обидно тоже. Моя сборка CMake смогла отловить кучу ошибок статического анализа, которые привели к множеству проблем и легко решаемы, но я слишком устал от споров с разработчиками об этом на GDC, чтобы сообщить об ошибках или даже попытаться исправить их. Моя энергия и мое психическое здоровье лучше потратить на что-то другое.

Нет мира, в котором scons смогут справиться с предстоящим дизайном модулей C ++ 20, как бы я ни кричал, как это сломает многие инструменты. Он не может обрабатывать отслеживание зависимостей для этого и потребует от него наличия шага предварительного сканирования, что еще больше замедлит отслеживание зависимостей.

Наконец, я собираюсь посоветовать людям не пытаться улучшить инструмент, который может принимать только незначительные изменения. Scons потребовалось бы полностью переписать с нуля и внести большое количество критических изменений, чтобы получить те улучшения, к которым здесь стремятся.

Я предлагаю закрыть этот вопрос, поскольку на GDC 2019 был дан ответ на обсуждение изменения системы сборки, но лидеры даже не думают, что стоит тратить свое время, чтобы прокомментировать эту проблему, что, я думаю, показывает, насколько они заботятся об эргономике. развития.

Мне кажется, что если бы существующая система сборки была на 100% преобразована по принципу plug and play, у разработчиков не было бы причин не переключаться.

Строить только на Linux бесполезно. Наличие игрового движка, который не работает на Windows, отпугнет серьезных разработчиков игр.

Я хотел бы создать впечатление, что разработчики игр достаточно заботятся о том, чтобы изменить систему сборки, чтобы удовлетворить ее пользователей.

Одна из причин, по которой я покинул Unreal, заключается в том, что движок предназначен в первую очередь для создания Blueprint / интерфейса игры. Создание инструментов в модулях C ++ в Unreal чрезвычайно болезненно и сложно.

Пока что в Годо было прилично приятно. Ускорение сборки C ++ было бы большим плюсом для сообщества.

IIRC они используют Wine для запуска инструментов сборки MSVC. Все еще не меняет вашей точки зрения, и я согласен.

Строить только на Linux бесполезно. Наличие игрового движка, который не работает на Windows, отпугнет серьезных разработчиков игр.

Godot всегда можно было построить на многих платформах, не только на Linux ...

IIRC они используют Wine для запуска инструментов сборки MSVC. Все еще не меняет вашей точки зрения, и я согласен.

Официальные сборки Windows компилируются с использованием MinGW; мы не используем WINE для запуска MSVC в Linux.

@marstaik - если вы переключаете сборки и запускаете scons только для создания файлов проекта MSVS, вы должны иметь возможность указать эти файлы в качестве целевых и не выполнять полную сборку.

так что постарайтесь:

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

SCons должен иметь возможность делать это, не выполняя полную сборку, а также должен делать это правильно, без необходимости сначала выполнять чистку.
(Кстати, я сопровождаю проект 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 Приведенное выше обсуждение очень хорошо подводит итог:

Я закрою это, потому что за эти годы мы ясно дали понять, что априори не собираемся менять систему сборки. Мы довольны SCons, и любые его недостатки можно и нужно оценивать индивидуально, как в рамках нашего собственного использования SCons, так и в восходящем направлении, если это связано с самим инструментарием.

Перехода на «более прохладную» сборку ради этого не произойдет. Подавляющее большинство основных участников довольны использованием SCons, и это тот, который мы теперь знаем лучше всего. Переход на новую систему сборки требует затрат как на реализацию, так и на обучение, и пока не доказано, что это того стоит.

В общем, изменение системы сборки - это не то, что мы можем принять от новых участников. Это должно происходить изнутри, и все основные участники должны рассматривать это как положительное изменение, чтобы оно имело какой-либо смысл. Мы не будем менять систему сборки только для того, чтобы угодить новым пользователям, которые пытаются собрать Godot из исходного кода и которым почему-то не нравится, что им приходится вводить scons вместо cmake или meson которому они привыкли. Мы также не будем принимать попытки ввести необязательную новую систему сборки - по опыту я знаю, что это может привести только к несогласованности, ошибкам и различиям в выводах.

Конечно, мы готовы изменить свое мнение, если можно будет перечислить явные достижения (и показать их с работающим доказательством концепции), которые перевешивают затраты на изменение системы сборки, но на сегодняшний день и после двух лет обсуждения здесь я лично не Не вижу стимула.

@ slurps-mad-rips хорошо сказал.

Это сложно, потому что здесь используются бра.

а также

Моя сборка CMake смогла отловить кучу ошибок статического анализа, которые привели к множеству проблем и легко решаемы.

Утончаюсь отвратительным , что CMake не серьезно рассмотреть вопрос , я могу думать о многих причинах канавы SCons, но КОНКРЕТНО , что CMake находит ошибку Scons не находит делает это «стоит» использовать что - то другое.

Переключения на "более прохладную" сборку ради этого не произойдет.

CMake не "круче", это стандарт. Если бы вы действительно использовали это, вы сразу поймете, почему.

Конечно, мы готовы изменить свое мнение, если можно будет перечислить явные выгоды (и показать их с работающим доказательством концепции), которые перевешивают затраты на изменение системы сборки.

Я не уверен, что кто-то готов изменить свое мнение. Опять же, @ slurps-mad-rips показала явный выигрыш, и она даже сделала всю работу ... Это уже сделано.

Стыдно, выражая официальную позицию команды Godot, полностью игнорировать ее усилия по улучшению процесса разработки.

Я вполне понимаю вашу боль, но все же согласен с другими - все строят
системы имеют свои
плюсы и минусы и в целом то же самое. Редко бывает какая-то техническая причина
чтобы изменить это.
Что касается политических соображений, они вам долго не дадут ничего хорошего.
бег. Все
предпочитает что-то другое. В любом случае никто никому не мешает делать вилки
для чего бы то ни было
причины, так что я думаю, что это так же хорошо, как и другие.

В пятницу, 21 февраля 2020 г., в 13:38 dorkbox [email protected] написал:

@ slurps-mad-rips https://github.com/slurps-mad-rips сказал это хорошо.

Это сложно, потому что здесь используются бра.

а также

Моя сборка 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=AAABPU2PBIEK6PFKQ2LDTHLRD6VKVA5CNFSM4ENJ6NN2YY3PNVWWK3TUL52HSG43JNV2KVWWK3TUL52XG4DFVM8VWWWK3TUL52XG4DVBWWBXWMXWW9BWMXWM8BWMX4DVBW9
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/AAABPU746R4YFHAI73Z57RTRD6VKVANCNFSM4ENJ6NNQ
.

@dorkbox - cmake обнаружил ошибки статического анализа? или это был вывод базы данных компиляции из cmake, запущенный через инструменты статического анализа llvm, который их нашел?

@bdbaddog , @ slurps-mad-rips сделали всю работу над этим, и было бы лучше спросить ее. (Я думаю, это будет результат статического анализа llvm, но я не тот, кто проделал работу по сборке с помощью cmake)

@slapin

Редко есть какие-либо технические причины для его изменения.

Как насчет инструментов статического анализа и поддержки современных языковых функций?

@bdbaddog @dorkbox Я просто включил clang-tidy, чтобы искать такие вещи, как «возврат ссылок на нестатические локальные переменные » и «переполнение буфера» через CMake. Я также провел проверку на лязг по нескольким вещам и получил еще несколько результатов. Мне также удалось запустить include-what-you-use , и он обнаружил довольно много ненужных включений заголовков.

Тем не менее, я фактически не «закончил» порт cmake. Часть, которая так и не была перенесена, - это вся работа, которую я проделал, пытаясь изменить текущие скрипты Python, которые просто вызывают f.write в каком-то файле для создания файла из JSON. Мне удалось удалить большую часть этой логики и заменить ее генератором шаблонов на основе jinja2. Это также решило проблему взлома, которую текущая сборка scons делает в окнах, где она запускает скрипт как исполняемый файл.

Однако я надеялся сохранить паритет со сборкой scons и, по крайней мере, объединить мои изменения в генерации кода. Этого не произошло, потому что скрипты python, используемые для генерации исходных файлов, постоянно меняются и синхронизируют эти изменения. с моей шаблонизацией jinja2 было упражнением в разочаровании.

Учитывая решительное и твердое «нет», которое я получил от ведущих разработчиков на встрече GDC GitHub, я решил, что больше не хочу участвовать в godot. Мои изменения были нежелательными, нежелательными, и они безразличны к чьему-либо мнению по этому поводу. Я не буду участвовать ни в Godot, ни в каких-либо вилках Godot. Желаю всем удачи в попытках убедить ведущих разработчиков в этом вопросе, но это все равно, что разговаривать с кирпичной стеной. Непоколебимый, непоколебимый и равнодушный к тяжелому положению всех участников этой цепочки.

Так что, если SCons может выдать базу данных компиляции, которая вводится в инструменты llvm, то это также можно будет сделать из SCons.

Так что, если SCons может выдать базу данных компиляции, которая вводится в инструменты llvm, то это также можно будет сделать из SCons.

Похоже, что с SCons творится ошибка невозвратных затрат. Почему бы не использовать что-то более простое, оптимизированное и уже являющееся частью существующих инструментов сборки, например cmake?

С сайта scons:

По сравнению с scons CMake:

• Быстрее
• Требуется меньше кода для общих задач
  
  
  
  • Возможно более стабильный
  
  
  • Поддерживает вывод в такие проекты, как Code :: Blocks, Xcode и т. Д., Чего не поддерживает scons.
  
  

@dorkbox - я соруководитель проекта SCons. Я просто слежу за желаемой функциональностью.

В последних нескольких выпусках и предстоящем улучшена производительность.

Кроме того, у нас есть PR для генерации файлов ниндзя, а у некоторых членов сообщества есть инструменты для компиляции базы данных. Так что некоторые из проблем, вероятно, будут решены (по крайней мере частично, если не полностью) в следующем выпуске.

Мне не известно о каких-либо проблемах со стабильностью, влияющих на проект godot, которые мы не рассмотрели. Если есть какие-либо неурегулированные вопросы, сообщите нам об этом.
(Свяжитесь с нами через: https://scons.org/contact.html)

Я не уверен, что cmake действительно требует меньше кода для общих задач, мне было бы интересно провести разумное сравнение.

Что ж, что меня больше всего раздражает в scons, так это то, что они не умеют генерировать простые старые
GNU make makefile. Отсутствие ниндзя - я могу с этим жить.
Также обработка утилит кросс-компиляции, таких как CMake toolchains и autotools.
возможности кросс-компиляции - сильное слабое место cmake.
В остальном все в порядке, так как я не человек IDE. Моя IDE - это среда UNIX.

В воскресенье, 23 февраля 2020 г., в 22:05 Уильям Диган [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=AAABPU5TQQFET5RS2JDRY7TRELCHDA5CNFSM4ENJ6NN2YY3PNVWWWK3TUL52-5DFVREXG43VLH4DFVREXG43V2HS4DFVREXG43V2
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/AAABPU6UHPX3HJTWPAFTPATRELCHDANCNFSM4ENJ6NNQ
.