CMake 3.28

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

добавь сюда дерего исходников

ну вот и добавь - в мейкфалах этого нет

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

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

Повторяю: он в корпоративном сегменте жилее всех жильцов.

Ну так я же и не спорю, разве гугл не корпоративный сегмент? Я так и говорю, что за счёт гугла жив. И будет жить пока гугл его двигает. Но может они его и доделают когда-нибудь. Основа-то хорошая. Допилить думаю можно.

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

Ну так надо тыкнуть в своей ide на корень исходников, дать ей фалги компиляции (в compile_flags.json), которые содержат и инклуд пути, и используемые библиотеки, дефайны, и вообще всё необходимое.

Если твоя IDE не может стартануть имея эту инфу, то она на букву Г должна называться.

Винда ведь не просто так идёт «своим путём», плевать им на удобство, портирование, переносимость. Им нужна своя паства. Значит винда соблюдать стандарты не хочет, а вот кресты должны вкрутить в себя систему сборки, чтобы везде собиралось. А может им на йух надо сходить?

Да, для хелловорлдов они могут показаться оверкиллом

Одно это уже ногоу. Простые вещи должны делаться просто. Иначе не взлетит. Ты покажешь этот хеллоуворд и 99% покрутят пальцем у виска.

Одно это уже ногоу. Простые вещи должны делаться просто.

Т.е. ногоу для простых вещей. Вот пускай и делают простые вещи на чём-нибудь простом – например, тут выше упоминали тупо shell-скрипт с одной командой компиляции. Собственно, сам я так и делаю. А для вещей на полкопейки посложнее пишу простенький makefile.

Ну вот и сделали симэйк, которого хватает для 99% проектов. А если кому-то нужно что-то сложное, нестандартное пусть пишет свою собственную систему сборки на чём угодно, почему нет?

Ну так я же и не спорю, разве гугл не корпоративный сегмент? Я так и говорю, что за счёт гугла жив.

Это, по вашему, логика? При чём тут гугл, если его используют конторы от мировых гигантов, до яндекса с касперским?

Основа-то хорошая. Допилить думаю можно.

Сэр, заканчивайте с этим. :) Вы будете нетфликсу рассказывать, что его можно допилить, и тогда, пожалуй, пользуйтесь? Нет, они вашего разрешения на это не просят, и ваше мнение про его допил их тоже не интересует. По тому, что просто пользуются. А вне корпоративного сегмента он и не собирается выходить.

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

Потому что его в гугле разработали. В нём и используется.

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

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

Нетфликс это который сериалы клепает? А как он его допилит и зачем? И вообще, нафига нетфликсу система сборки?

Не, я имею в виду авторов базеля, которые в гугле сидят. Если допилят, то шансы есть. Не допилят, так он там и будет дальше вариться, по корпорациям… А жаль, в принципе задумка-то неплохая. Мог бы выйти в люди.

Не, я имею в виду авторов базеля, которые в гугле сидят. Если допилят, то шансы есть. Не допилят, так он там и будет дальше вариться, по корпорациям…

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

А жаль, в принципе задумка-то неплохая. Мог бы выйти в люди.

Ему фиолетово на ваше мнение. К тому же, вы, похоже, просто потролить решили.

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

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

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

Ещё как вариант, может быть, кто-то форкнет и доведёт до ума.

Ему фиолетово на ваше мнение.

Да я как бы и не навязываюсь.

Да ёпта, вам тут дет сад что ли? :) Я вам ещё раз говорю: каждая монорепа, где используют базель - она по объёму превосходит, не знаю там, все вместе взятые репозитарии СПО, использующие симейк, например. А вы про какое-то «массовое использование» толдычите, да вы в своём уме то хоть? :)

И вовсе незачем так истерить. :) Массовое использование - значит использование в ширнармассах, в разных окружениях, а не внутри десятка контор, пусть даже у них тонны кода.

До какого ума, ёперный театор? Это инструмент для монореп с хулиардами строк кода в каждой. Вам такие объёмы и в страшном сне не снились, а вы твердите про «допил и выход в люди»?

Что мешает довести до ума инструмент для монореп с хулиардами строк кода в каждой? Почему бы и нет? Не вижу препятствий.

Они же как-то пользуются gcc или clang для своих монореп? Никто не истерит на форумах, «как же ты будешь пользоваться clang, который используется для монореп!».

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

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

Что мешает довести до ума инстумент с хулиардами строк кода в каждой?

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

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

Да я же не навязываюсь. Какая разница, сколько строк он собирает, если для массового использования он непригоден? Я вроде бы внятно объяснил. Пофигу, сколько он там строк собирает, если у него не решены проблемы с обратной совместимостью, к примеру. А без этого широкое применение невозможно.

что мешает построить у вас во дворе ядерный реактор

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

Если есть аргументированное возражение, почему это невозможно или ненужно, готов послушать.

А без этого широкое применение невозможно.

А оно и без того - шире некуда. Им что, очень нужно, чтобы и вы на нём свой хелло ворлд собрали? Нет, им вообще это не нужно.

Как раз в случае базеля довести до ума вполне возможно

До чьего ума, до вашего? Им имеющегося спектра применения хватает с лихвой. Никакая другая система сборки по масштабам внедрения (по общему объёму собираемого кода, а не по кол-ву хэллоуворлдников) с ним и близко не сравнится. А за хеллоуворлдниками они и не гоняются. Это инструмент для монореп.

А без этого широкое применение невозможно.

А оно и без того - шире некуда.

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

Бред же. Сам же сказал что только для монореп и крупных контор.

Так я что, виноват, что эти объёмы внедрения, по кол-ву собираемого кода, превосходят всё остальное вместе взятое? Их такой расклад вполне устраивает. А до хэллоуворлдников им дела нет.

Я говорю как раз о широком применении, в разных окружениях.

Ну так это вы говорите. А им на ваше мнение, как бы, фиолетово. Ради вашего хелловорлда, а так же и ради ещё тысячи других хэллоуворлдов, они и пальцем не пошевелят.

Ну так это вы говорите. А им на ваше мнение, как бы, фиолетово. Ради вашего хелловорлда, а так же и ради ещё тысячи других хэллоуворлдов, они и пальцем не пошевелят.

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

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

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

Так это из серии «вот ядерный реактор бы доработать, а то, чего это я его не могу у себя на даче поставить? за свет дорого платить стало, хочу ядерный реактор!». Да не будут его для вас дорабатывать.

Вот ежели, допустим, к ним из Наса придут, и скажут: «слушайте, ну что-то вот у нас тут сборка стала подтормаживать, после того, как объёмы исходников за 10Тб перевалили… вы бы тут ни пооптимизировали кешинг чуток? а может ещё какую-то сверх-быструю ФС нам под это всё предложите?» - вот на это бы они ответили. По тому, что это - их кейс. И именно в этом направлении они хотят свой продукт улучшать. Другие направления их не интересуют.

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

А он и так массовее некуда, по объёму собираемого кода.

Так это из серии «вот ядерный реактор бы доработать, а то, чего это я его не могу у себя на даче поставить? за свет дорого платить стало, хочу ядерный реактор!». Да не будут его для вас дорабатывать.

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

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

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

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

Кстати почему никто не вспомнил про базель? Очень даже хорошие идеи заложены. Но не взлетит конечно.

Пробовал. Он оставил у меня ощущение очень приятного по синтаксису и вместе с тем сырого продукта.

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

Пробовал. Он оставил у меня ощущение очень приятного по синтаксису и вместе с тем сырого продукта.

Точно! У меня тоже. Такое впечатление что бросили не доделав.

А так давно уже никто не делает. Все оставляют autogen.sh

У меня ровно обратная информация. Впрочем наличие мегабайтного configure совсем не радует.

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

Будто кто-то тебе запрещает

tup

О, любопытная штука

Многие просто «не в теме»

Это мы-то не в теме? Вполне адекватный тред, разные мнения, аргументы, примеры. За всеми спикерами чувствуется опыт

Ваше решение поставленной задачи?

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

Ваше решение поставленной задачи?

А есть ещё более правильное решение: быть для начальника настолько полезным работником, чтоб он тебя слушал, а не наоборот

А так давно уже никто не делает

Ещё как делают. Configure-скрипт готовый раза в два чаще встречается, чем autogen.sh

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

у cmake есть одна важная особенность: он работает. А все остальные… Мейкфайлы приходится править в большинстве случаев, потому что запилившие их умники опять про что-нибудь там не подумали. Про кросс-компиляцию вообще молчу. Мезон не интегрируется с IDE и на любой чих предлагает написать шелл-скрипт - а что делать, если мне это еще под виндой собирать? И т.д. и т.п.

Потому что кроссплатформа это множество, в которое помимо онтопика входит и оффтопик.

Если найдёшь цитату, где я прошу кого-то его для меня доработать

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

Единственная проблема, из-за чего базель не может стать популярным

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

Нет никакой проблемы собрать хеловорд базелем.

Да давно ли для сборки хелловорлдов, стало модным ЖДК тянуть? Вы это серьёзно вообще?

Вполне адекватный тред, разные мнения, аргументы, примеры.

О make, cmake, ... конечно в теме, а вот о том почему эти ЛАБЫ разработали в треде не было суждений.

ЛАБЫ, это не упрёк разработчикам make, cmake, ..., а акцентирование того, что если в код
добавить возможность предоставления линкеру метаданных о используемых библиотеках, то
потребность в использовании make, cmake, ... станет в разы меньше.

Sorry, будет «шик, блеск, красота».

Вот есть кроссплатф-ый проект на 3 платформы win/mac/linux. Как мне его собирать? Держать три проекта под msvc/xcode/make ? - очень удобно.

ВНЕЗАПНО да, держать три проекта под Windows/Mac/Linux может быть удобнее, по крайней мере для проприетарной разработки. Уже писал про это в другом посте. В двух словах - сложность поддержки трех проектов сильно преувеличена. А сложность зазубривания уродского велосипедного языка CMake и ковыряния в груде CMake костылей наоборот сильно преуменьшена. Все равно практически в любом CMake-базед проекте сложнее хелловорлда приходится постоянно городить портянки if(WIN32) ... elseif(APPLE) ... else() ... endif() и забивать туда платформенно-специфичный код. Что не сильно далеко ушло от поддержки трех разных файлов проектов. В CMake хоть варнинги можно кроссплатформенно включить или до сих пор надо пердолить if/else/endif под каждый компилятор?

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

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

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

Взамен мы полностью лишаемся удобной настройки проекта из гуйни Visual Studio и XCode. Все что раньше делалось в несколько кликов мышью, теперь требует написания портянок скриптушни на уродском нетипизированном DSL с отвратительной документацией. Стоит ли оно того? Ну не знаю, решает каждый сам для себя.

Кстати для scala есть sbt (стандарт де-факто, и не без причин).

Прикольно, не знал, всегда думал что JVM-базед языки используют Maven или Gradle. Интересно, почему в ФП языках таки додумались до императивных скриптов сборки на тех же самых языках, а в мейнстриме - нет.

Так себе преимущество: вся эта фигня просто БЕШЕНО тормозит.

Сильно сомневаюсь, что оверхед от std::filesystem::path вообще будет заметен в сборочных скриптах, которые 99% времени тратят на ковыряние в файловой системе и вызовы компилятора с прочими утилитами. Зато std::filesystem::path - это отдельный типобезопасный класс без неявных преобразований в строчки с пачкой полезных методов. Мне например не хватает такого класса в культях. Там только строчки QString плюс помойка QFileInfo, в которую беспорядочно свалены как методы для работы с путями, так и собственно методы для получения информации о файлах.

Ниньзя мне не нужен. … А как этой хренью пользоваться — нет.

Достаточно просто поменять генератор в cmake на -G Ninja и при сборке вызывать ninja, а не make и всё. Чего там сложного не понимаю. Руками писать Ninja скрипты нет необходимости, это всё автоматически генерируестя.

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

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

Да может и не сложно. Только зачем? У меня был проект с нуля. Надо было что-то портировать с винды, библиотеку какую-то собирать. Был CMakeLists для винды то ли написанный, то ли сгенеренный. Ну и встал выбор, чем собирать. Ну cmake — понятно, он есть и больше ничего не требует. Связка meson-ninja потребовала поставить кучу питоньего хлама, который мне ну нахрен не нужен. Да еще и из этой дискуссии выяснилось, что для полноценной работы мезона надо ставить что-то локально через pip. Не уж, нахрен. Разводить питоний бардак ради непонятно чего? Мой проект ну сильно меньше гнома и не требует сложной процедуры сборки, как у systemd. Вот как питонсты разберутся со своим бардаком и для установки пакета мезона из репы будет достаточно питоньих пакетов оттуда же, тогда и будем посмотреть.

Да. Из более-менее больших проектов, tup используется в KolibriOS.

На VMS портировать сильно проще, чем с VMS. :) У тебя в VMS какой-нибудь индексный файл тупо «иcкаропки» (ну да, РАБы-ФАБы :) ), а что делать бедному юниксоиду в этом случае? BerkelyDB прикручивать?

Так с OpenVMS пришлось портировать много чего. Интеловская версия появилась не сказать чтоб давно. А вот это гораздо большая проблема, чем наоборот.

Кстати для scala есть sbt (стандарт де-факто, и не без причин).

Прикольно,

Так что сформулированное EXL правило «в IT всегда становится негласным стандартом самое всратое решение» иногда-таки даёт сбой. :)

Хотя я конечно и sbt обосрать могу, да и саму скалу тоже, но это будет уже из серии «There are only two kinds of languages: the ones people complain about and the ones nobody uses» (c) Bjarne.

Он, по кол-ву собираемых исходников, давно всех превзошёл на порядки.

Слушай, а все-же, откуда такая информация?

если в код добавить возможность предоставления линкеру метаданных о используемых библиотеках, то потребность в использовании make, cmake, … станет в разы меньше.

Спорно

В Visual Studio любую опцию можно установить в исходном коде (в т.ч. метаданные об используемых библиотеках).
Для сборки проекта программисту не нужно вникать и настраивать мегабайтные конфиги.
Весьма удобно!

Да никто и не сомневается, а кросс-компиляция? А сборка под другие ос? А сборка другим компилятором? А публикация проекта?

Ну и далее по списку. Ты тут такой умный выскочил с одной фичей, а все остальные тут дураки по 20 лет жрут кактус и просто не знали про твою вс-студию.

Открою тайну: все знают, ан нет, смотри-ка, пользуются и симейк и мейк и мезон и ещё массу всего. Наверное есть причины

Слушай, а все-же, откуда такая информация?

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

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

Да давно ли для сборки хелловорлдов, стало модным ЖДК тянуть? Вы это серьёзно вообще?

технически это выглядит как

 apt install bazel

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