CMake 3.28

Но это все равно не объясняет, почему большинство завязалось на CMake.

Меня больше интересует, почему не стал популярным tup? Уж Lua (в случае такой необходимости) всяко поприятней скриптов CMake.

UPD. Поскольку пример по ссылке – убожество без хелперов, вот так выглядит cakefile.cpp одной из моих библиотечек.

Прикольно! А что понимается под хелперами? Это вспомогательные крестофункции, которые создают более сложные правила сборки под конкретные задачи (типа компила С++ проектов) через голый Make-like v.rule()? Берутся они из сошек вроде dimgel-svlen1[-DEBUG].so, dimgel-zs1-buildtime[-DEBUG].so?

А что понимается под хелперами? Это вспомогательные крестофункции […] через голый Make-like v.rule()?

Да, всё так. rCompile(), rLink*() – в самом <cake/aux.h>, а svlen1 и zs1 – это отдельные проекты, трансформаторы кода на clang libtooling.

	US<R> rrCompile(Oven& v, DirMaker& dm, const rrCompile_Params& pp) {
		US<R> objs;
		if (!pp.cpps.empty()) {
			objs.reserve(pp.cpps.size());
			for (auto& cpp : pp.cpps) {
				auto srcPfx    = pp.srcPfx   .ends_with('/') ? pp.srcPfx    : pp.srcPfx    + '/';
				auto targetPfx = pp.targetPfx.ends_with('/') ? pp.targetPfx : pp.targetPfx + '/';
				auto o = util::fs::changePrefixAndExt(srcPfx, targetPfx, cpp, "o");
				auto d = util::fs::changeExt(o, "d");
				objs += v.rule(o, parseDFile(v, {.cpp = cpp, .d = d, .o = o}) + pp.morePrereqs, {
					// ATTENTION: `o` is passed by value.
					{[&v, &dm, o] {
						if (v.verbose(Verbosity_Default)) {
							v.getLog().compile("%s", o.c_str());
						}
						dm.mkdirRecursive(util::fs::getParentDir(o));
					}},
					pp.cc + V<S>{"-o", o, cpp}
				});
			}
		}
		return objs;
	}

Но это все равно не объясняет, почему большинство завязалось на CMake.

Очевидно потому что альтернативы тогда не было. Я писал примерно тогда 2001 сборку средненького проекта на чистом make. Проект поддерживал сборку на виндосе и линуксе, кросскомпиляцию на несколько платформ, я даже слепил генерацию проектных файлов для вижуал студио и кодекомпозера от техас инструментс (и даже частично импорт из них обратно). И это всё работало, конечно, но… Это было больше похоже на магию для других разработчиков в этом же проекте. Слишком сложно для понимания. CMake облегчает и упрощает многие стандартные задачи своими многочисленными готовыми встроенными командами.

Потом какое-то время работал с tmake и qmake, но те были слишком привязаны к Qt.

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

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

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

Редко вижу крестовика, который бы реально хорошо разбирался в CMake.

Редко вижу крестовика, который бы реально хорошо разбирался в c++…

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

Не-не-не.

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

Я использую cmake где-то с 2007 года. Да, он крив, но геморроя с ним меньше чем с альтернативами. Мне еще раньше нравилась возможность генерации vcproj, но сто лет уже не пользовался этим функционалом. FindXXX.cmake почти все кривые, я по возможности вызываю pkg-config из cmake.

Мой опыт в основном это использование CMAKE для сборки ИХ ЖЕ проектов типа VTK.

Впечатление - ЖУТЬ.

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

Да, иногда ОНО собирается после долгих танцев с бубном. Но потом приходит другая версия и ВСЕ падает. Особенно классно оно падает с использованием CUDA. Это вообще отдельная песня. Если собирать с CLANG, который по идее сам бы мог собирать под CUDA то вызывается NVCC с CFLAGS от CLANG, которые он не понимает… И все падает. Приходится специально использовать тормозной GCC иногда в 1 поток… и отказываться от стандартных родных же LDFLAGS, ну потому что они обязательно передаются NVCC, который их О чудо! не понимает… и ругается как таракан который лежит на спине.

При этом, БЛИН, (там было другое слово)

Я не писал НИ CMAKE ни скрипты для него и VTK c его убитой системой сборки тоже не писал.

Я просто вызываю cmake с нужными CARGS согласно manual. А потом я хожу и читаю сотни страниц почему ЭТО не работает. И меня иногда убивают ответы, что мол CMAkeLists.txt нужно было писать по другому…

Кто бы все эти советы передал авторам одновременно CMAKE и VTK.

P.S. И кто бы что ни говорил, но немцы не умеют в программирование. SAP это наверно лучший пример в этой сфере, хотя CMAKE тоже не далеко ушел.

А где этот Cake можно скачать (в смысле исходный код)?

У нас все проекты под cmake и это пистец. Кто что поменял и сборка ломается, надо заново генерить все.

У нас все проекты под cmake и это пистец. Кто что поменял и сборка ломается, надо заново генерить все.

М-да, «Налево пойдёшь, в дурдом попадёшь, направо пойдёшь в CMAKE попадёшь».

«Нет повести печальнее, чем эта».

PS: На ЛОР много подобных тредов.
Поэтому-то и использую бесплатную Visual Studio 2013.
Non problem вести разработку кроссплатформенного API, которое без проблем можно использовать и в Linux.

Visual Studio Express?

https://learn.microsoft.com/en-us/visualstudio/releasenotes/vs2013-community-vs

https://microsoftportal.net/microsoft/4160-microsoft-vypustila-besplatnuyu-ve... Microsoft выпустила бесплатную версию Visual Studio

К сожалению в LAW «не бум-бум», но похоже для open source бесплатна.

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

Я думаю, он имел в виду, «не понимают, зачем было писать на нём автотулзы». Как препроцессор, я его использую. Но когда я смотрю на автотулзы, то не особо понимаю, почему их надо было обязательно делать на препроцессоре. :)

полоумные фанатики CMake … продолжают писать такие же велосипеды

Ты так и не ответил, что делать в твоем любимом meson если нет pkg-config. Сразу отметаем cmake-велосипеды как ненужное говно, а потом что? Делаем более другой велосипед, написав портянку из питоньей дристни?

anonmyous ★

Оспади, напугал. Я уж подумал что анону звезду дали)

Да они там что, почкованием размножаются? Откуда он взялся, и зачем? :)

У меня такой вопрос ко всем системам, кроме мейка, включая сабж

Вспомнил такую проблему. После отработки find_library() она запишет наденные пути к библиотекам и инклюдам в переменные.

Но названия этих переменных не заданы жёстко и приходится угадывать в какую переменную автор скрипта засунул найденные пути. Кто-то пишет LIB, кто-то LIBS, у одних DIR, у других DIRS и т.д.

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

Пытаться читать исходный код скрипта это анрил. Там часто дремучие портянки.

Нарушение правил регистрации. У меня тоже глаз зацепился за этот ник.

мейк - и не система сборки

А что?

на голом мейке, тоже можно… При условии 1 единственной целевой системы, где ничего не меняется, все зависимости всегда на месте и их версии одни и те же всегда

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

Вообще касательно критики синтаксиса и поведения CMake был хороший и конструктивный пост от бывшего разработчика ЛОРа тут

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

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

Вот у меня щас такой. Мейкфайле в пару сотен строк, куда ещё проще. Чего сложного это поддерживать?

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

Мы не против нового, тока на хрена новую ложку изобретать?

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

Ой, да ладно, зато поржали)

А где этот Cake можно скачать (в смысле исходный код)?

А нигде. Я в опен-сорц уже наигрался.

Ты тоже сидишь без инкрементальной сборки? У меня проект с нуля собирается 20 минут. Хочешь тратить столько времени после любого даже самого малого изменения в коде?

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

Ты тоже сидишь без инкрементальной сборки?

Ты точно мейком пользоваться умеешь?

А либы искать тоже ифдефами?

Что значит искать либы?

А кросс-компиляторы?

А что с кросс-компиляторами?

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

Да, все так и было. Опишу личный опыт. Помню, под вантуз обычно создавали проект Visual Studio, под мак делали проект XCode, под онтопик заводили мейкфайл и писали код в каком-нибудь Code::Blocks. Позже стали использовать Qt Creator с qmake. Основным эталонным проектом обычно считался студийный и вся разработка шла в первую очередь там. Затем проекты под другие платформы периодически синхронизировали со студийным. Чаще всего синхронизация сводилась к простому добавлению новых С++ файлов в проект.

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

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

Ты точно мейком пользоваться умеешь?

Нет конечно. Зачем мне эта страхолюдина.

Однако я дежурно напоминаю, что чтобы правильно инкрементально собирать например c/c++ нужно парсить файлы и извлекать оттуда список инклюдов и добавлять их в зависимости. Make этого не умеет. Хакиры конечно, придумали костыль в виде ключиков для gcc, но это не make, о котором мы здесь говорим, это сторонняя пришлёпка.

Мейкфайле в пару сотен строк, куда ещё проще.

Пока туда стороннему человеку не пришлось заглянуть. Потому что стандартов никаких нет и каждый пишет как хочет. У меня был негативной опыт линковки с одной библиотекой. Там автор тоже был хакиром и сделал сборку на самописном makefile.

Мне нужно было пересобрать её с другими ключами компилятора, но автор об этой возможности нормально не позаботился и мне пришлось долго копаться в этой лапше, состоящей на половину из make, а на половину из шелл команд с if’ами. А всё из-за того, что там была поддержка кросскомпиляции и вариантов статической и динамических сборок. Но инструмент — make — был для этой цели выбран неправильно.

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

Универсальных систем сборки со своим собственным велосипедным DSL и так уже наплодили хоть попой жуй. Может стоит теперь задуматься об узкоспециализированных системах сборки? Ну чтобы например сборочные скрипты для крестопроектов писать на тех же самых крестах, а не учить всратый CMake, который ни для каких других задач больше не пригодится? Например как build.rs в расте или Setup.hs в хаскеле.

В треде уже кидали годные примеры подобных скриптов сборки на С++. Да, для хелловорлдов они могут показаться оверкиллом по сравнению с несколькими строчками на CMake. Но как только логика сборки усложняется и размер CMake скриптов переваливает за несколько тысяч строчек, очень быстро начинает не хватать полноценного ЯП со статической типизацией и нормальной поддержкой в IDE.

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

Ещё подкину wake. :)

Wake is a build orchestration tool and language.
If you have a build whose steps cannot be adequately expressed in make/tup/bazel/etc, you probably need wake.
If you don’t want to waste time rebuilding things that don’t need it, or that your colleagues already built, you might appreciate wake.

Пример:

package build_wake

from wake import _
from gcc_wake import _

# Prefer to use system utf8proc if available
def utf8proc variant = match (pkgConfig "utf8proc")
    Some x -> Pass x
    None -> vendor @here variant "2.2.0" `.*\.h|utf8proc_data\.c` `utf8proc\.c`

Ты точно мейком пользоваться умеешь?

Нет конечно. Зачем мне эта страхолюдина.

Однако, критикуешь.

Потому что стандартов никаких нет и каждый пишет как хочет

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

У меня был негативной опыт

Так про что угодно можно сказать и это почти всегда правда)

автор об этой возможности нормально не позаботился

Всякое бывает

автор тоже был хакиром и сделал сборку на самописном makefile.

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

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

Пост-фактум все умные

Если бы ...
Годами наблюдаешь лишь один «умный» трёп в форумах.

В форумах много: артиллеристов, физиков, философов, ... , а разработчиков мало.
Это как на базар физику ядерщику прийти и «обсудить».
Многие просто «не в теме», но «знают» и «учат».

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

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

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

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

У тебя есть идеи, как можно сделать билдовую систему с такими требованиями? Подумай об этом. А мужики (я имею ввиду авторов автотулзов) на этом собаку съели: у них есть не только идеи, но и работающая реализация.

Если почитать ман, становится ясно какие цели стояли перед этим проектом и почему они получились именно такими.

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

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

После отработки find_library() она запишет наденные пути к библиотекам и инклюдам в переменные

Это ты про что рассказываешь? Если про cmake, то современном cmake эта проблема решена с помощью модулей. Легаси это проблема, да. Но в принципе эта проблема решена.

Он давно уже взлетел

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

Всё ещё жив за счёт гугла, судя по всему. В свободном плавании - не жилец.

Хорошо. Предположим, что к вам приходит начальник и говорит: теперь к проекту присоединяется ещё и Вася. Сделай так, чтобы этот проект открывался во всех обычных IDE и не просто открывался, а чтобы и дерево файлов было видно и автодополнение работало, в общем все плюшки IDE чтобы функционировали.

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

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

Это при условии, что проект тащит с собой сгенерённый конфигуре-скрипт на пару сотен килобайт, и плюс ещё кучу вспомогательных скриптов, типа config.guess, install-sh и тд. А так давно уже никто не делает. Все оставляют autogen.sh, но тогда - требуется и автоконф, и автомейк, и либтул.

Всё ещё жив за счёт гугла, судя по всему. В свободном плавании

• не жилец.

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

MSVC

Зачем его использовать для сборки кроссплатформенного софта?

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

Вот только не надо безосновательных обобщений.

после того, как популярные IDE (CLion, Visual Studio, Qt Creator) добавили поддержку CMake. Типа раз большие дяди его юзают, то и нам надо срочно на него переходить. Карго-культ, все дела

Ты говоришь про карго культ не понимая всех причин.

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

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

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

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

Друг, как человек, потративший 15 лет своей жизни, портируя свободное ПО на отличную от unix систему с ограниченным posix - а именно OpenVMS - я тебе скажу, что «проблема» с конфигурированием на такие системы - это детская шалость по сравнению с самим портированием. Симейки, автотулзы, ниньзи и прочая хрень это такая мелочь смешная… Даже написание своего конфигуратора - займет лишь маленькую толику твоих затрат. Поверь мне, у чувака-программиста Бионика совсем не о конфигураторе голова болит. И читать эти баталии фанатов конфигураторов на полном серьезе происходящие, просто смешно. Ребята просто не знают настоящих проблем.

Число комментариев: 404

Хехе

Этакий build.cpp.

Кстати для scala есть sbt (стандарт де-факто, и не без причин). Его билд-скрипты пишутся на scala, императивные. Т.е. для какого-то специфического функционала, ради которого для maven пришлось бы писать отдельный проект-плагин, на sbt можно вшить всю логику в сам билд-скрипт.

использует std::filesystem::path вместо примитивных строк

Так себе преимущество: вся эта фигня просто БЕШЕНО тормозит. Гы, как и полагается сраной прослойке. Так что мой выбор – строки и syscalls (а точнее обёртки над ними, бросающие исключения).

А почему это вообще система сборки должна думать об IDE? Почему не наоборот? Шлангу для дополнялок хватает compile_flags.json, добавь сюда дерего исходников - любой IDE должно быть достаточно для старта.

А так хвост виляет собакой, всякие IDE и виндоуз, которые клали болт на POSIX. Make, shell, окружение - всё это стандартизировано, вопросы надо задавать тем, кто им не следует. А CMake - куча кривых костылей. Винда должна вкрутить в себя POSIX shell, make, pkgconfig, и прочие утилиты, CMake все дружно вынесут на мороз. До этого ни один приличный разработчик не должен ничего писать под это недоразумение с особым путём.

ограниченным posix - а именно OpenVMS - я тебе скажу, что «проблема» с конфигурированием на такие системы - это детская шалость по сравнению с самим портированием.

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