Вышла новая версия CMake 3.16.0

Не пробовал, поэтому предполагать не буду. Хотя поддержка fortran компиляторов вроде как есть.

систему сборки и пакетный менеджер нужно делать частью языка

А если проект писан не на одном языке? Вот как выше спросили смесь С с Fortran?

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

Само понятие «система сборки» – это уже имбецилизм прошлого века. Ты ещё что-то там на вонючий autotools гнал, а сам дрочишь просто на другое говно, но всё равно на говно. Это всё равно что сравнивать cvs и svn, вместо того чтобы просто использовать git. Думается, что «системы сборки» специально придумали в качестве коллектора для кретинов. Просто чтобы они трахались с ними, и не лезли в код. Весьма умное решение. Столлман таким вгонял толпы школьников в депрессию, которые мнили себя мамкиными кулцхакерами.

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

Само понятие «система сборки» – это уже имбецилизм прошлого века.

Ваши предложения? Чем собирать монстурозный проект на 100500млн строк из 10ти языков?

Закапывают qbs, а qmake пока остаётся резервной системой, хотя развиваться не будет.

Эх, добавили бы нативную поддержку верилога, а то тулы cadence с поддержкой msie и многопоточной элаборации/компиляции приходится интегрировать через custom_target’ы и разруливать ад зависимостей на большом проекте.

систему сборки и пакетный менеджер нужно делать частью языка

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

Оптимизировать под 95% окупается. Тогда быстро развивается экосистема.

Остальным можно дать возможность к расширению, к интеграции других систем сборок.

Более того что чаще всего проекты не состоят из микса языков в одинаковых ролях. Обычно есть основной код и завёрнутые библиотеки. Вот для этого придумали горы врапперов.

вменяемого аналога с затягиванием зависимостей по конфигу

начнутся вскукореки про монорепы. это же исходники надо конпелировать - слишком сложно для с/с++. давай лучше готовый curl.dll с warez.org - вот это было бы норм.

давай лучше готовый curl.dll с warez.org - вот это было бы норм

Я думаю, он имел в виду тянуть в исходниках.

На QMake далеко не уедешь.

слишком сложно. а сборочные скрипты откуда? а субмудуль оно само сделает? это думать надо. не, давай curl.dll скомпиленый visual studio 2015, збс будет экосистема.

CMake теперь поддерживает Objective-C и Objective-C++

Очень вовремя.

На QMake далеко не уедешь.

В смысле? Нормальная такая тяговая лошадка. И очень компактная по записи. Да, парсер можно было бы сделать более вменяемым.

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

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

Ваши предложения? Чем собирать монстурозный проект на 100500млн строк из 10ти языков?

Моё предложение – продолжать говорить школьникам и умственно отсталым, что системы сборки, любые, – говно для имбецилов. И когда нарисуется какой-нибудь вася с традиционным вскукореком: «а что ваще», – продолжать это делать.

Лично мня радуют все существующие системы сборки – нужно же как-то занимать кретинов, чтобы не лезли в код.

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

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

Нет, сам перфокарты прокалывай.

ну cmake объективно становится говном тем сильнее, чем более хитрую сборку на нём надо описать :)

Тогда, действительно, в сторону waf посмотри. Замастерить его еще тяжелее, чем CMake, и документацию еще нужно разобраться, как вкуривать, но поглядывая на примеры и исходники более-менее реально. Да и Наги специфичный чувак…

Там «навешивать» всякие штуки на таргеты как раз более удобно, и добавлять поддержку других языков.

Фактически, это три в одном: на верхнем уровне ты описываешь свои таргеты и из чего они состоят. Только в отличие от add_custom_* на таргеты вешаются «фичи». Затем второй уровень, эти фичи трансформирует в низкоуровные таски (что-то ближе к рулям ниндзи и мейка), и собственно, на самом нижнем уровне сам шедулятор этих тасков.

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

Из минусов - интегрируется с IDE только через кастомные таски (то есть надо вызывать из командной строки), но сейчас почти все умеют в compile_commands.json, поэтому киллер-фича CMake, где он генерирует солюшен, уже не так актуальна. Да и у тебя, для верилога, наверное не работало.

Не вариант, как раз интеграция с IDE и ctest это то, ради чего с cmake и связались, чтобы все программные тесты можно было вытащить как подпроект из сборки микросхемы, и отгрузить в виде bare metal SDK самого первого. А уже его некоторые потребители хотят вообще в винде собирать.

🤷‍♂️ мое дело предложить. Cmake умеет для верилога v?proj генерировать или в чем интеграция заключается? Ещё как-то не очень понял про программные тесты. Я в создании fpga совсем мало знаю 😐

В смысле?

С кросс-платформенностью там плоховато и с подключением сторонних библиотек.

DSL у QMake по степени упоротости может потягаться с CMake’овским. Чего, например, стоит захаркоженный стиль кодирования 1TBS:

static 
{
   something
}

# ^ Parse Error ('static') Unterminated conditional

static {
   something
}

# ^ Ok

Но, даже QMake использовать приятнее, чем CMake, спору нет.

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

Вся экосистема плюсов говно говна.

Сок, так сок. Ещё круче.

Ну ещё из полезных тулзов могу порекомендовать Conan.

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

Его под embedded тоже пытаются пользовать, например include os. Да и вообще для корпоративной разработки штука приятная. Я с его помощью blinky делал ☺️ бутстрапил gcc-arm, openocd и ещё утащил у modm инициализацию. Поинт был как раз в использовании привычных тулзов (vs Code в моем случае), причем с полноценным пониманием всех define и навигацией по коду и дополнением (да, для blinky это тоже важно 😁), а не какой-то стремный Arduino ide… И все это прозрачно и однообразно и на линуксе, и на винде.

С другой стороны, если уж у вас куча всего понаписано под cmake, лучше не трогать, пока совсем не припрет…

Но у autotools есть одно преимущество перед cmake - его можно запустить где угодно где есть sh и make

И это далеко не единственное преимущество.

• Простота кросс-компиляции: configure –host=$(то-что-написано-в-начале-твоего-gcc). Не надо писать на каждый чих тулчейн-файл.
• configure, созданный autoconf, всегда имеет опцию –help c человекопонятным описанием опций проекта. В случае с cmake лучшее, что есть - это ccmake (или cmake-gui), в которых а) нужно повозиться, чтобы отделить опции коретного проекта от всего остального и б) их интерфейс явно не рассчитан на отображение справки длинней одной строки на каждую опцию (да и хорошо, если авторы проекта вообще хоть что-то там пишут). Кроме того, cmake позволяет легко и непринужденно создавать недокументированные опции проекта, узнать о которых можно только из его кода
• проект на autotools поддерживает набор стандартных переменных, которые можно задавать на стадиях configure и make. В cmake поддерживается не все, не везде, и многое зависит от доброй воли разработчика проекта.

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

Посмотри в сторону опции link_language. До версии 0.51 было автоматическое определение, это решили дополнить явным указанием компилятора.

Уже был питонорождённый scons, теперь у нас питонорождённый meson. Потом ещё какую-нибудь новую хрень придумают на питоне.

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

vcpkg же есть, пользуйся.

CMake норм, ты просто его готовить не умеешь.

(Справедливости ради — большинство проектов его тоже готовить ни черта не умеют.)

CMake норм, ты просто его готовить не умеешь.

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

То есть это такой аналог рыбы фугу. Приготовишь неправильно — скопытишься.

Все могут, а С++ не может. Я думаю ерунда, надо начать делать.

Ага, ерунда. Всего-то сорокалетний язык с десятком+ систем сборки.

В Комитете таки хотят что-нибудь с этим сделать, есть подгруппа про это. Но сначала модули.

Согласен, как пользователю мне autotools очень нравится.

И это далеко не единственное преимущество

И правда.

• Истинная кроссплатформенность: самая популярная ОС и ее компилятор для автотулзов не существуют. Главное - существуют все платформы, если они GNU. Хотя бы притворяются GNU.

• Библиотечка, собирающаяся за 2 секунды, с автотулзами будет собираться всю минуту, что добавляет энтерпрайзности. Матрица в консоли при этом повышает уровень хакерства.

• Ахив с исходниками библиотечки вырастает в размерах на порядок за счет нечитаемых талмудов на древних языках. Еще больше энтерпрайзности.

• Неважно, что все равно придется установить сборочное окружение на полгига минимум. Главное - ничего специально не надо устанавливать, только sh и make!

• И вообще, какая эстетика: смесь sh, m4 и perl. Для тех, кто познал жизнь.

Вроде того.

Главное - существуют все платформы, если они GNU

ЛПП, изначально автотулзы предназначались для портирования софта на всевозможные юниксы, ИЧСХ успешно решали эту задачу.

С виндой, конечно, не все так гладко, но даже для msvc есть обертка

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

Откуда такие цифры?

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

Откуда такие цифры?

И вообще, какая эстетика: смесь sh, m4 и perl. Для тех, кто познал жизнь

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

Хе-хе. Boost.Build.

Только мир, он того, сложнее, чем просто C++. Там и кодогенерация, многоязыковость и ещё черт с тарелочками.

Я в своё время просто изучал шаблоны CMakeLists.txt, которые KDevelop использует. И вообще, чем тебе цикл статей Linux format не нравится?

Точно, хелп - основная причина из-за которой ненавижу cmake. Конечно можно посмотреть опции в ccmake, но почему бы их не пихнуть в хелп?

Ох уж этот кэш...

Ну так автотулзы не просто так ненавидят. Но всё же мне было очень приятно запустив кое-как компилятор на андройде и притащив gmake туда собрать там less не притаскивая ещё чего-то

Поставишь в дебиане компилятор, binutils и dev пакеты для иксов и полгига наберётся точно. dev пакеты ещё и статиклибы содержат

в винде приходится прописывать к этой библиотеке абсолютный путь

Есть же $$PWD.

Каждый раз как собираю ffmpeg под виндой проклинаю autotools. Более забагованного и тормозного ужаса придумать невозможно.

Вот да, мне интересно, те, кто за автотулз топят тут, аргументируя, что cmake сложный, сами пытались что-то аналогичной сложности на этом м4 написать?

Чего, например, стоит захаркоженный стиль кодирования 1TBS:

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

С кросс-платформенностью там плоховато и с подключением сторонних библиотек.

Тут вопрос — а где лучше?

В Комитете таки хотят что-нибудь с этим сделать, есть подгруппа про это.

ВАААААУ!

У них есть уже какие-то черновики, наработки? Интересно было бы почитать…