CMake 3.28

Да какая разница, «для меня, не для меня»?

А, ну то есть цитат не будет?

Вы пишете полный и откровенный неадекват

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

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

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

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

Он, по кол-ву собираемых исходников, давно всех превзошёл на порядки. А в вашей голове он всё ещё что то там вам «должен, прежде, чем станет популярным». Вы неадекват?

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

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

А, ну то есть цитат не будет?

Специально для зрителей, показываю, что делает сей тип: CMake 3.28 (комментарий)

Цитата звучала так: «Такое впечатление что бросили не доделав.»

Он же её удалил, и написал «А, ну то есть цитат не будет?» Разумеется, мой коммент о том, насколько эта цитата абсурдна (как и все предыдущие высказывания данного оратора), тоже был удалён.

Тогда и посмотрим, кто из нас более адекватен.

Уже посмотрели. Достаточно.

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

Ну дальше можно и не цитировать очередной высер про то, как же плохо гугл вложил деньги в базель, как он его забросил и угробил, и как долго его ещё «пилить» до выхода в народ. :)

Ладно, всё. Это уже в игнор. Тут медицина бессильна.

В всех постах акцент был на то, что в Linux всё допотопно и давно пора эту проблему решить.

А почему это, внезапно, стало проблемой Linux? Не очередные костыли нужно вкручивать, а идти к унификации окружения, чем и является POSIX. Вопросы нужно задавать мелкомягким донам, почему вместо нормального posix шелла они вкручивают повер_щели всякие?

Всё, кроме унификации - очередные костыли, все эти билд системы, «давайте вкрутим в кресты чего-нибудь» - очередная ерунда с глубочайшей родовой травмой, лишь подмахивание господам из копрорраций. Не POSIX? Иди лесом. Вот каким должен быть разговор.

Хотя и мелкомягкие уже какие-то телодвижения делают со своими WSL’ами, не слежу и не пользуюсь, но направление верное.

Ладно, всё. Это уже в игнор.

Жаль конечно, что слился. Я ещё хотел ссылочку попросить «про в разы больше исходников».

Корпорации не защищаю.
Посты о том, что вопросы сборки могут быть решены, но к сожалению «воз и ныне там».

Все эти make, cmake, … - ЛАБЫ и не более того. Почему к примеру в Visual Studio у программиста нет проблем с линковкой? Всё просто! Программист может в коде поместить метаданные о используемых библиотеках.

Зато у программиста после этого будут проблемы с переносимостью.

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

Но это процесс очень медленный. А то что в Visual Studio экспериментируют, это хорошо. Может потом в стандарт предложат.

А то что в Visual Studio экспериментируют, это хорошо.

Вот.
Ведь мы разработчики и не пристало нам разделять всех на «белых» и «красных».
Почему бы хорошие технологические решения не перенести и в Linux.

Почему бы хорошие технологические решения не перенести и в Linux.

Разумеется идёт постоянный обмен удачными технологическими решениями. Но чаще, по понятным причинам, перенос идёт в обратную сторону, из Линукса и других открытых систем в Виндос и другие закрытые системы.

Сборка, это лишь одна из проблем в Linux.
Для меня загадка, почему десятилетиями их никто не решает.

Потому что закрытм системам нет никакого желания этого делать, им нужно быть особенными с армией личных адептов и фанатиков. Массы кушают и играются в эти игры. Венда крутится, бабки мутятся. Домохозяйке из зажопинска абсолютно плевать на проблемы переносимости, POSIX и криво-костыльного CMake, вендаХ - это модно и трендово, так девочки сказали. Linux - сложно и для задротов.

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

Если разработчки (как более продвинутые люди) перестанут терпеть такое и игнорить венду за такие фокусы, то только тогда может наступить перелом.

Странно, откуда появился запах политоты?)

Почему-то разработка Wine и Proton политотой не считается.
ИМХО не нужно создавать искусственно образы «врагов Linux».
Акцент диалога - пути решения проблем в Linux, а не её ущемления/шельмования.

У линукса нет проблем, он следует стандартам. Вопросы донам из MS, сколько ещё их болт будет лежать на стандартах?

Понял Вас.

Сборка, это лишь одна из проблем в Linux. Для меня загадка, почему десятилетиями их никто не решает.

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

В общем могу сказать только то, что у ГНУ/Линукс всё открыто и каждый может изучить исходники, разобраться и решить проблему. Это не значит что твоё решение непременно примут в официальную репу, но такая возможность есть, в отличие от собственнических систем.

Уже нет.

ВНЕЗАПНО да, держать три проекта под Windows/Mac/Linux может быть удобнее, по крайней мере для проприетарной разработки. Уже писал про это в другом посте. В двух словах - сложность поддержки трех проектов сильно преувеличена

Браво, гениально. Список исходников в трех местах. Список ассетов в трех местах. Какие-нибудь специальные действия, типа копирования ассетов или получение ревизии из git в трех местах. Шикарно.

В CMake хоть варнинги можно кроссплатформенно включить или до сих пор надо пердолить if/else/endif под каждый компилятор

Нужно (хотя есть CMAKE_COMPILE_WARNING_AS_ERROR, но я эту не использовал, поэтому не могу сказать, удобно ли это.), а в случае трех проектов не нужно?

msbuild для проектов визуальной студии, xcodebuild для XCode, ну и make само собой. Ну да, не унифицированно, а через if/else, но тебя же набивка аналогичных if/else в CMake скриптах тоже не смущает.

Набивка каких аналогичных if/else? Запуск будет ‘cmake –build …’

Взамен мы полностью лишаемся удобной настройки проекта из гуйни Visual Studio и XCode

Это субъективщина. Мне визуальные настройки неудобны.

Все что раньше делалось в несколько кликов мышью, теперь требует написания портянок скриптушни на уродском нетипизированном DSL

А по мне визуальная настройка в Xcode/VS - это уродское кликание по херовой горе окошек, что потом глаза вянут.

с отвратительной документацией

Не подтверждаю. Вполне норм доки. И достаточно подробные.

А теперь продолжим. Если я работаю в Qt Creator / CLion / Vim, что мне делать? Переучиваться на XCode / VS ? С хера ли?

А если я хочу попробовать собирать на Ninja ? - переписывать все на Ninja? Например мой текущий проект собирается на VS 12-13 мин, а на Ninja 10 мин. А если я хочу потом вернуться на VS то что снова переписывать?

А если я пишу опенсорс библиотеку (каких множество) и использую другие кроссплатформенные библиотеки, то то мой код будет тоже кроссплатформенный и код моего CMakeLists.txt тоже, и использование моей библиотеки на трех ОС также будет сведен к одинаковым вызовам нескольких cmake комманд. А если делать три проекта, то сколько дублирования будет по итогу, не хочешь сказать?

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

А CMake сейчас по сути стал некоторой формой замены этого формата. Его создатели правильно уловили потребности разработчиков. И не было бы этой необходимости - не было бы cmake.

Для оффтопика есть MSYS.

Картинка интересная, особенно пример команд, где CONFIGURE

ИЧСХ, никаких «огромных неудобств» это почему-то не создавало. Буквально повозюкал мышью в условном XCode проекте пять минут, накидал туда новых файлов драгдропом, потыкал гуевые настройки и вуаля - вот и тебе и поддержка нескольких проектов под разные платформы

Ну вот мой текущий проект на cmake под lin/win/mac. Вот допустим я запилил новый модуль/класс и т.п. Добавляю исходники. Рабочий ноут на винде и есть мак мини, линукс в виртуалке. По твоему сценарию мне нужно закомититься на винде, запушиться, включить виртуалку линукс, запулиться, внести изменения, звпушиться и еще повторить на маке. Супер!!! А сейчас я вношу изменения в CMakeLists.txt, запушиваю. Запускаю сборку на jenkins на трех системах, смотрю ок или нет и далее по таска процессам идет. Конечно же твой сценарий намного удобнее :-)

Msys штука специфическая. Некоторые либы можно под него не собрать.

Можно пример либы, которая собирается под линуксом, не собирается под MSYS, но при этом собирается под MSVC?

MinGW, если ты не в курсе, не соблюдает их C++ ABI. Да и Си не всегда совместим. :)

Взамен мы полностью лишаемся удобной настройки проекта из гуйни Visual Studio и XCode.

Хорошее дело гуйнёй не назовут ;)

Если так важно иметь возможность настройки из Visual Studio и XCode, то можно сделать какой-то скрипт для их импорта/экспорта в симейк. Хотя я не понимаю, что ты там, каждый день крутишь настройки компиляции?

Обычно прописал один раз настройки и забыл…

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

ты изменил задачу на ту, где симейк действительно нужен.

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

которые содержат и инклуд пути, и используемые библиотеки, дефайны, и вообще всё необходимое

по сути, CMake этим и занимается. Прописывать всё это вручную в проекте чуть сложнее калькулятора - это песец

В исходниках обнаружил полезный enum_set.

Не похоже, что они этим плотно пользуются. Вот сразу косяк:

  enum_set& operator+=(const enum_set& other) noexcept
  {
    this->erase(other);
    return *this;
  }

За забором, как следует из названия, должно много странного находиться. А там дрова лежат

Ну вот PyTorch например

https://github.com/pytorch/pytorch/issues/24460#issuecomment-1383277152

https://stackoverflow.com/questions/76153651/why-is-pytorch-failing-to-build-with-mingw

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

Почему к примеру в Visual Studio у программиста нет проблем с линковкой?

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

Т.е. в vs проблем с линковкой быть не может.

Суждение было о том, что программисту в Visual Studio не нужно анализировать мегобайтные конфиги.
Настройка сборки много проще, чем в cmake, ...

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

В целом, здравая идея. В установочном комплекте такой системы сборки поставлять компилятор C++ и библиотеки с функциональностью, аналогичной той, что дает сейчас cmake. Конфигурирование происходило бы гораздо быстрее. И писать с наличием нормальных типов данных было бы удобнее.

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

Приходилось создавать проекты для Visual Studio для многих популярных проектов и это не сложно.
Впрочем наверное от того, что «знаю как».
Опыта в использовании cmake, ... нет.
Если cmake, ... удобны и просты, то почему на форуме их частенько критикуют?

Приходилось создавать проекты для Visual Studio для многих популярных проектов и это не сложно.

Я не говорю, что сложнее чем на cmake. Я говорю, что вариативность действий равна вариативнасти настроек этих действий.

Если cmake, … удобны и просты, то почему на форуме их частенько критикуют?

Ну не всем нравится. VS тоже критикуют. Вот меня например бесит обилие кнопочек и вкладок vs.

А меня нет.
Йоги на голове стоят днями и СЧАСТЛИВЫ.

Ну в целом да, только вот вместо простого

$ pkgconf --libs --cflags sdl2
-I/usr/include/SDL2 -D_REENTRANT -lSDL2

cmake предлагает проштудировать и юзать эту портянку. И так во всём. А генерация IDE’шного мусора это вишенка, кричащая о всей ущербности этого поделия.

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

Помнится генерил модуль для либы
Если это ок, то лучше я выйду:

if(opt_install)
  include(CMakePackageConfigHelpers)
  write_basic_package_version_file(${PROJECT_NAME}ConfigVersion.cmake
    COMPATIBILITY AnyNewerVersion
    ARCH_INDEPENDENT)
  install(FILES ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake
    DESTINATION lib/cmake/${PROJECT_NAME})

  install(TARGETS tabl curtabl stream_pipe EXPORT
    ${PROJECT_NAME}Config)
  install(EXPORT ${PROJECT_NAME}Config
    NAMESPACE ${PROJECT_NAME}::
    DESTINATION lib/cmake/${PROJECT_NAME})
  # Adds *Config.cmake to the build dir.
  export(EXPORT ${PROJECT_NAME}Config
    NAMESPACE ${PROJECT_NAME}::)

  install(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/include/
    DESTINATION include/${PROJECT_NAME})
endif()

PS: тут, чуть больше чем cmake модуль, но дух CMake’а отражает, это безумие.

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

Не осилил? Бывает…

Нет, просто надоело жрать дерьмо.

Реакция «зелен виноград» выступает способом самозащиты от фрустрации путём обесценивания цели.

А что за цель? Выработать толерантость к CMake’у? Ну да, сорян, подвёл команду, не могу более сдерживать рвотные позывы.

Йоги на голове стоят днями и СЧАСТЛИВЫ.

А это те, которые пачками в микрософте работают? Ну им то на иголках спать и не есть месяц за счастье.

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

Я тебя понимаю, у меня такое же к VS/Xcode. Двадцать раз кликни для элементарной фигни.

Шутка

Эээээээээээ, эти борщ едят палочками.

Браво, гениально. Список исходников в трех местах. Список ассетов в трех местах. Какие-нибудь специальные действия, типа копирования ассетов или получение ревизии из git в трех местах. Шикарно.

Сложность поддержки трех проектов, как я уже писал, сильно преувеличена адептами CMake. Файлы и ассеты перетаскиваются мышью в проект за пару секунд. Для многих намного удобнее сделать это два/три раза в IDE, чем вбивать списки файлов руками в CMake скрипте. Для выполнения специальных действий в гуевых настройках есть всякие Pre/Post Build Events. Опять же, не составляет особых проблем забить туда нужные команды на поверщели или баше. Тем паче, что многие ассеты типа иконок и ресурсов изначально платформозависимы, лежат по разным путям, имеют разные форматы, и даже в CMake один хрен приходится использовать if/else/endif.

а в случае трех проектов не нужно?

В случае трех проектов ты просто открываешь настройки проекта в IDE и тыкаешь мышью в человекочитабельные и понятные опции аля Warning Level или Pedantic Warnings. А не ковыряешься в if/else/endif скриптушне и не выискиваешь флаги компилятора вроде /W3 и -Wall.

Набивка каких аналогичных if/else? Запуск будет ‘cmake –build …’

Ну а в случае трех проектов запуск будет через условный if (вантуз) msbuild ... elseif (мак) xcodebuild ... else make ... endif. Сложно? Да как-то не особо. В CMake скриптах ты же как-то привык набивать if/else/endif и не считаешь это чем-то зазорным. Вот и любителям трех разных проектов сборка разными командами через if/else/endif тоже норм.

Это субъективщина. Мне визуальные настройки неудобны.

Да, это субъективщина. Поэтому я не призываю всех срочно бросать CMake и перебегать на проекты IDE. Просто описываю личный опыт. Многим после удобств проприетарных IDE симейк скрипты кажутся регрессом и деградацией. Лично наблюдал обратную миграцию с CMake на Visual Studio и Xcode в одном из проектов. CMake там остался чисто для сборки под онтопик вместо мейкфайлов.

Не подтверждаю. Вполне норм доки. И достаточно подробные.

Норм доки - это например Qt или MSDN. А CMake - это все что угодно, только не нормальные доки. Хуже этих доков может быть разве что их отсутствие.

Если я работаю в Qt Creator / CLion / Vim, что мне делать? Переучиваться на XCode / VS ? С хера ли? А если я хочу попробовать собирать на Ninja ? - переписывать все на Ninja?

В проприетарной разработке ты как правило будешь писать на том, на чем тебе скажут. Если брать десктопную разработку, то почти наверняка это будут Visual Studio и Xcode. Популярность CLion и Qt Creator можно приблизительно оценить по ежегодному опросу StackOverflow. И хаотичные метания с MSVS на Ninja и обратно скорее всего не поприветствуют. «Миша, у тебя скучное лицо, тебе никто денег не даст» (c).

В проприетарной разработке вообще очень часто сборка намертво захардкожена. На каждой платформе используется ровно один компилятор. Проект собирается строго с фиксированными конфигурациями. Произвольная настройка через пользовательские опции (команда option в CMake) отсутствует. Зависимости кладутся в папочку 3rdparty и пути к ним хардкодятся в проекте, без всякого там поиска системных библиотек. Никто не будет тратить деньги и время разработчиков/тестировщиков на супер-пупер конфигурируемую сборку, позволяющую на лету менять компиляторы и библиотеки. И вот в таких условиях гибкость и расширяемость CMake оказывается по большей части бесполезной. Возникает вопрос - а не проще ли вместо CMake тупо использовать раздельные проекты Visual Studio и Xcode, идеально заточенные именно под проприетарную разработку?

А если я пишу опенсорс библиотеку (каких множество) и использую другие кроссплатформенные библиотеки

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

По твоему сценарию мне нужно закомититься на винде, запушиться, включить виртуалку линукс, запулиться, внести изменения, звпушиться и еще повторить на маке.

Все верно. По личному опыту в десктопной разработке этот подход ВНЕЗАПНО неплохо работал. Основным и эталонным проектом обычно считался студийный. Именно он пилился и тестировался в первую очередь. Где-то ближе к концу очередного спринта, обычно с периодичностью в две-три недели, Mac и Linux версии синхронизировались с вантузным. Чаще всего этим занимался отдельный разработчик, так что виндузне не требовалось заводить виртуалки и разбираться в никсах. Обычно вся синхронизация сводилась к добавлению недостающих файлов в Mac/Linux проекты, реже к мелким правкам компиляции, натыкиванию #ifdef и дописыванию платформо-зависимых частей.

Конфигурирование происходило бы гораздо быстрее. И писать с наличием нормальных типов данных было бы удобнее.

Именно. Как только объем CMake скриптов переваливает определенный порог, поддерживать их становится очень невесело. Полюбуйся например на тонны CMake скриптопараши в движке O3DE. Разрабы настолько задолбались с этим убогим высером, что от безысходности часть скриптов написали на питоне. Естественно у них есть отдельные папочки CMake скриптов под каждую платформу (Android, Linux, Mac, Windows, iOS), где лежит чуть ли не половина всех файлов. Кроссплатформенный CMake такой кроссплатформенный.

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

Можно пример либы, которая собирается под линуксом, не собирается под MSYS, но при этом собирается под MSVC?

QtWebEngine еще например. Она использует хромиум, который на оффтопике официально поддерживает только MSVC и шланг (через обертку clang-cl).