Представлен релиз кроссплатформенного открытого генератора сценариев сборки CMake 4.1.0, выступающего в качестве альтернативы Autotools и используемого в таких проектах, как KDE, LLVM/Clang, MySQL, MariaDB, ReactOS и Blender. Код CMake написан на языке C++ и распространяется под лицензией BSD...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63713
В каком интересно месте он "простой языка сценариев"? По-моему он давно примкнул к тем кого должен был заменить
Тоже обратил внимание, что все альтернативы старому-доброму make почему-то сложнее и только продолжают бухнуть. Может конечно возможность выкачивать зависимости с гитхаба напрямую и есть хорошо, но вот эта вечная беготня с «да что перестроить уже, чтобы ты готовую либу всё же увидел» и жонглированием трудночитаемыми конфигами напрягает.
А сколько дыр через все эти навороченные системы сборки пролезает...
Крепитесь: всё чаще попадаются C/C++ проекты со сборочными скриптами на питоне.
Так питон идеальный язык для быстрого написания скриптов. Разве не так? И да, meson открой для себя.
На мезоне сидят гтк, вяленд, системд и оригинальный ксорг, что как бы намекает.
У мну в генте по-моему все эти сборочные системы есть. Точно видел cmake, meson, ninja ,%SUBJ% и может еще кого-то. Но особо внимания не обращал, т.к. после запуска emerge @world обычно иду спать :).
Версии сборочных системы не всегда совместимы как тотже Conan (1.x vs 2.x) в отличие от CMake
А почему не на расте?
> А почему не на расте?Угадай с трех раз, на чем пишутся сборочные скрипты для проектов на расте ...
что там гадать.
toml & rust (build.rs)
и Lua (xmake с xrepo в китайских проектах)
Питон это Meson или Conan
Большое спасибо, я посмотрел и проникся. Даже FPC поддерживает.
>все альтернативы старому-доброму makeЯ тебе маленький секрет открою. На выходе cmake генерится старый добрый Makefile.
Да он CMake и не пользуется.И наверняка вообще имеет условное отношение к разработке на C или C++, ибо собирать сколь-нибудь большой проект на этих языках при помощи голого make - это чистый мазохизм. Коллеги тебе этого тупо не дадут сделать.
Эти коллеги в вкусно-и-точка скоро работать уйдут, т.к. иишка всех лоускилов выкидывает уже с рынка. Я вот стартап пилю и там только Make, т.к. это мегаудобно все вспомогательные действия держать в 1 месте а не плодить кучу мелких скриптов. И действия - любые, а не только предусмотренные авторами смаке. И качать зависимости можно хоть с гитхуба хоть откуда прозрачным способом и билдить их какой угодно сторонней системой сборки, просто сделав соответсвующий таргет. При этом собственно сборка всех с/с++ файлов проекта - 7 строк.
> Эти коллеги в вкусно-и-точка скоро работать уйдут
> Я вот стартап пилюНу, то есть, на мороз пока выкинули только тебя. 😂 Стартап, лол...
> все вспомогательные действия держать в 1 месте а не плодить кучу мелких скриптов
И весь исходный код тоже в одном файле, надеюсь? 😂 Хотя, когда у тебя хэллоуворлд - это не проблема, так ведь?
> И действия - любые, а не только предусмотренные авторами смаке
А, ну понятно: еще один эксперт, который CMake в глаза не видел, рассказывает об его ограничениях. 🤦
> И качать зависимости можно хоть с гитхуба хоть откуда прозрачным способом и билдить их какой угодно сторонней системой сборки, просто сделав соответсвующий таргет. При этом собственно сборка всех с/с++ файлов проекта - 7 строк.
Ты не поверишь, но в CMake тоже так 🤯. Только вот работать оно будет на всех системах (даже Винде), а не только в юниксовом окружении.
Ну каг бе стратап зарабатывает уже неплохо, есть некоторый штат сотрудников, а я за CTO. Я заранее подготовился, а кого-то вот ждёт неприятный сюрприз. Кусочки кода, которые узко смотрящие кодеры могут писать, давно уже нейронка делает.> эксперт, который CMake в глаза не видел
15 лет в IT за деньги, а так ещё больше.
> даже Винде
А мне не надо чтобы на венде работало (но там вообще-то есть линукс окружение и собрать можно если не лоускил или хотя бы дипсик осилил).
> есть некоторый штат сотрудников, а я за CTOТы уж определись, СТО ты или кодер-писатель make. 😂
> 15 лет в IT за деньги, а так ещё больше
Жаль, что не на позиции разработчика. 😂 А то в любом серьезном проекте ты за ручное написание make получил бы по шапке уже в первый месяц. 🤣
> А мне не надо чтобы на венде работало
Да я и не сомневался. Только вот тем, кому это надо - используют CMake.
> но там вообще-то есть линукс окружение и собрать можно если не лоускил или хотя бы дипсик осилил
Тебе об этом тот самый Дипсик сказал? Спроси его заодно, зачем мне там на Винде "линукс окружение", если проект собирается с msvc.
> Ты уж определись, СТО ты или кодер-писатель make.Тут некоторые жалуются мол синтаксис непонятный. Чатик всё напишет если что-то нетривиальное нужно. Лычку мастера мейкфайлов иметь не обязательно, достаточно иметь положительный iq. А так я много чё делаю, RnD всякое, деплой, настройка системы, оптимизация нейросетевых моделек - не только код пишу. Поэтому make как инструмент автоматизации не только лишь сборки - мастхэв.
> если проект собирается с msvc
Кто в здравом уме в 2к25 будет планировать стартап под венду? Либо под мак писать надо, т.к. деньги там, либо веб, котороый на линукс / wasm кругом, либо хардварный стартап с прошивками - там опять же msvc ненужон. Везде Make как родной. Если игру делать - то они все на готовых движках со своими билд системами.
>Если игру делать - то они все на готовых движках со своими билд системами.Не знаю, у меня что сборка исходников, что уровней, что моделей, всё в батниках с компиляторами.
>за ручное написание make получил бы по шапке уже в первый месяцА разве уже не достаточно?
cmake
cmake --build
cmake --install
CMake использует Ninja (когда доступно)
я тебе маленький секрет открою.
СMake никогда не был альтернативой make.
СMake стартанул как альтернатива autotools.
Согласенcmake ./
make
Давно уже генерится ninja. Потому что make не умеет не только в конфигурацию проекта, но и в собственно сборку.
Мне make не нравится своими тонкостями, которые необходимо помнить. Но вот что бы он в сборку не умел. Я чего то не знаю - получается. Что за проблемы у make со сборкой?
> Тоже обратил внимание, что все альтернативы старому-доброму makeА make когда-то был системой сборки? 😂
А что - когда то не был? O'Riley :-?
:)
А не что тот факт, что cmake - это генератор Makefile'ов, т.е. аналог autotools. Makefile, cгенерированный cmake'ом, затем внезапно запускается в обычном make.
CMake поддерживает несколько генераторов. Ninja намного производительнее чем Make
> Ninja намного производительнее чем MakeЭто миф. Ninja просто запускает подготовленные кем-то (basel например) команды из compile_commands.json.
1. если в makefile просто засунуть список этих команд, без вычисления зависимостей, то отработает за +- то же время, но так люди не делают, т.к. не читаемо.
2. ninja отрабатывает после генератора этого compile_commands.json и если сложить время, то оно будет больше чем у нормального человеческого Makefile из нескольких строчек.
> ... команды из compile_commands.json🤣🤣🤣
>> Ninja намного производительнее чем Make
> Это миф. Ninja просто запускает подготовленные кем-то (basel например) команды из compile_commands.json.Вот такие вот истории со срывами покровов получаются, когда стартапного СТО познакомить с DeepSeek... 🤦
Чатик мне запилил так-то рабочий скрипт для конвертации мезон либ в тупо папку в проекте с исходниками парсингом compile_commands.json, так что я в курсе, как это работает. Makefile в отличие от cmake не требует указывать каждый C/C++ файл (тот так может но криво и ломается так сборка постоянно, поэтому у смачников сизифов труд по добавлению каждого с файла в смаке). Т.к. мне не нужно иметь кучу раздутых so всё собирается статически с едиными флагами в компактный бинарь.
И да, я использую генерацию кода - и что вы мне сделаете) Раздутый штат кодеров больше компаниям не нужон.
> рабочий скрипт для конвертации мезон либ в тупо папку в проекте с исходниками парсингом compile_commands.jsonПопроси чатик объяснит смысл этого набора случайных слов, ибо я лично распарсить его не смог.
> Makefile в отличие от cmake не требует указывать каждый C/C++ фай
CMake тоже не требует. Спроси у своего чатика о CONFIGURE_DEPENDS.
> Т.к. мне не нужно иметь кучу раздутых so всё собирается статически с едиными флагами
Ага, все сторонние либы, да еще и C с C++ вперемешку - с едиными флагами? 😂 Ну сказано же: мастер хэллоуворлдов, реальных кодовых баз в глаза не видавший.
> И да, я использую генерацию кода - и что вы мне сделаете)
Проявим сочувствие. Ну, насколько это возможно к "стартапному СЕО, по совместительству писателю мейкфайлов при помощи DeepSeek" 🤣
> я лично распарсить его не смогНе мудрено для i shaped специалиста по смаке. Поясняю - берётся мезон либа, указываются нужные флаги, мезон генерит compile_commands, скипт на питоне достаёт оттуда пути к собираемым файлам, фиксит корявые пути к инклудам и кладёт с/с++/h файлы в отдельную папочку внутри Makefile проекта. Всё, больше мезон не нужен.
> C с C++ вперемешку - с едиными флагами?
Да, прикинь? Проект на C/C++ с едиными флагами (кроме версии стандарта языка разве что, это включено в CC/CXX переменную)
app: $(patsubst %.cpp,build/%.cpp.o,$(SRC_CPP)) $(patsubst %.c,build/%.c.o,$(SRC_C))
$(CXX) $^ $(LFLAGS) -o appbuild/%.c.o: %.c
$(CC) $(CFLAGS) -I$(dir $<) -MD -c $< -o $@build/%.cpp.o: %.cpp
$(CXX) $(CFLAGS) -I$(dir $<) -MD -c $< -o $@-include $(patsubst %.cpp,build/%.d,$(SRC_CPP)) $(patsubst %.c,build/%.d,$(SRC_C))
И всё! Надо будет - добавлю go / swift / что угодно компилируемое.
> Проявим сочувствие
Учитесь, пока не поздно) Либо правильному промптингу нейронок, либо котлету на булку класть)
> Поясняю - берётся мезон либа, указываются нужные флаги, мезон генерит compile_commands, скипт на питоне достаёт оттуда пути к собираемым файлам, фиксит корявые пути к инклудам и кладёт с/с++/h файлы в отдельную папочку внутри Makefile проекта. Всё, больше мезон не нужен.Т.е. из человеческого, поддерживаемого Meson файла ты сделал write-only портянку make на выброс, с прибитыми гвоздями инклюдами и по пути угрохав даже *внутренние для либы* флаги компиляции? 😂
Не, ну это гениально! Вот оно - последствие влияния нейронок на неокрепшие умы вайтишников. Вайб-кодерам хоть простительно - они в код не смотрят, а тут...
> Да, прикинь? Проект на C/C++ с едиными флагами (кроме версии стандарта языка разве что, это включено в CC/CXX переменную)
"Прикинь 😧" у тебя будет, когда ты прекратишь сочинять находу и действительно попробуешь таким подходом скомпилировать что-то больше своего хэллоуворлда. И в тот же самый момент до тебя дойдет, зачем нужны билд-системы. даже в пределах одного окружения.
> I$(dir $<) -MD -c $< -o $@
> И всё!Апхапхах! "И все!" А эти все глупцы десятилетиями Автомейки с Симейками зачем-то придумывают. Узрите, несчастные, как стартапный СТО заменил все ваши поделия одним заклинанием make!
> Т.е. из человеческого, поддерживаемого Meson файлаНаоборот же мезон мне поддерживать не нужно а либу нужно было допилить поэтому удобнее всё в единой системе сборки держать. Пересобирать либу снаружи проекта через мезон и дольше и неудобнее чем используя инкрементальную пересборку Make проекта.
> прибитыми гвоздями инклюдами
А инклюды как раз из хрен пойми каких путей преобразуются просто в путь к папке этой либы в проекте как и для всех остальных модулей. Поэтому инклуды разных модулей мне не нужно указывать в общих флагах.
> write-only портянку make на выброс
7 строк всего для сборки C/C++, переиспользую из проекта в проект. Типичная мезон/смаке портянка куда больше т.к. в смаке каждый исходный файл проекта перечисляют.
> стартапный СТО
Сам-то чего добился ?)
> build/%.c.o: %.cну сразу приехали. Ты просохатил зависимости от .h
Про то что это фу-фу-фу gnu make only уж не будем (этот, хотя бы, все еще собирается в любой мыслимой и части немыслимых сред, где хотя бы есть posix shell и не очень безнадежно старый gcc)то есть для одноразовой поделки прокатит, для своего проекта уже непригодно сходу.
Нет они учтены в -include $(patsubst %.cpp,build/%.d,$(SRC_CPP)) $(patsubst %.c,build/%.d,$(SRC_C))
> Нет они учтены в -include $(patsubst %.cpp,build/%.dИ кто вот это всьо генерить должен - руками каждый .h добавляешь, что-ли?
make dep не просто так был придуман в auto* подходе.
GCC сам же и генерит d файлы, в которых в понятном мейку виде лежат зависимости от h файлов.
> А не что тот факт, что cmake - это генератор Makefile'ов, т.е.
> аналог autotools.ни разу не, потому что autotools - генератор _генератора_ мэйкфалов.
> Makefile, cгенерированный cmake'ом, затем внезапно запускается в обычном
> make.но только на той системе и только в той единственной конфигурации где был произведен.
А configure сгенерит тебе мэйкфайлы на ЛЮБОЙ поддерживаемой системе, с учетом твоих личных пожеланий. БЕЗ autotools. Они нужны только автору. И то не каждый день.Просто выросло поколение не умеющих ими пользоваться и не понимающее зачем оно вообще надо. (ни разу не для генерации мэйкфайлов было задумано)
>> Makefile, cгенерированный cmake'ом, затем внезапно запускается в обычном make.
> но только на той системе и только в той единственной конфигурации где был произведен.Ну да, в этом весь смысл. Кроссплатформенным инструментом является cmake, а не его выхлоп.
Или ты хочешь сказать, что в сценарии:
> configure сгенерит тебе мэйкфайлы на ЛЮБОЙ поддерживаемой системе
...получившийся Makefile будет работать не "только на той системе и только в той единственной конфигурации где был произведен"?
> Просто выросло поколение не умеющих ими пользоваться и не понимающее зачем оно вообще надоТак а действительно: зачем вообще надо использовать древний копролит из нагромождения Shell, Perl и M4, намертво прибитый к Unix-окружению и применяющийся сугубо в опенсорсном легаси?
А где ты там сложности вообще увидел? target_link_libraries не осилил?
В прошлый раз тут советовали писать тесты для оператора if, потому что по меркам CMake это сложная логика с проблемным легаси ("The if command was written very early in CMake's history..."), которое решили не чинить.
Не знаю, кто там тебе и чего советовал, но проект на cmake накинуть можно за пару минут.
Интересно, как скоро
а) язык конфигурирования сборочной системы СМаке оформится как отдельный, полноценнный Тьюринг-полный язык,
б) для которого нужен будет свой язык конфигурирования сборки?
так CMake уже Тьюринг-полный и скрипты можно запускать не в режиме сборки, а в режиме интерпретации через ключ -P
а) уже
б) Bazel. Нормальный высокоуровневый почти-пайтон, который CMake может генерить. Мы используем.
На работе, в основных проектах, был выбран CMake. Периодически приходиться нырять в эту чертовщину и чинить. Хорошо хоть появились форки CMake с поддержкой отладки.
Для домашних проектов использую premake5. С версии 5-beta6 появился API для управления зависимостями примерно как в CMake. Теперь можно описать как использовать либу, а потом просто воткнуть в проекте uses 'SDL3' и нужные опции прокидываются. Тут если что почитать можно: https://premake.github.io/docs/Usages-and-UsesКороче CMake не нужен, закапывайте.
> С версии 5-beta6 появился API для управления зависимостями примерно как в CMake.
> нужные опции прокидываются
> Короче CMake не нужен, закапывайтеТо есть недавно в бета-версии premake появилась опция, которая доступна в CMake уже лет 20? Уже бегу закапывать CMake!
>в основных проектах
>нырять в эту чертовщину и чинитьНаверное тут надо команду разработи менять, а не cmake.
> Наверное тут надо команду разработи менять, а не cmake.Упонминание в комментарии "uses 'SDL3'" говорит о том, что "комнда" состоит лишь из него самого, пишущего для себя игрушки.
явно ничего сложнее на cmake чем хелоу ворд не делал, cmake когда тянешь кучу blas, mkl или прочего сразу затыкается, т. к. или везде разные версии cmake саморезами прикручены или вручную каждую библиотеку в path прописывать, отлаживать эту подделку псевдоязыкописателей сложно
Все используют CMake, но писать на этом языке никто не хочет
Я тебя может удивлю, но пользователи cmake даже не используют. Только мейнтейнеры и изредка программисты.
Беда почти всех яп - чтобы собрать программу, надо выучить ещё один язык. Хорошо, что я сборщики себе на сях свои пишу.
что мешает писать все в одном файле? :)
Нужно умещать весь код в один экран, как это делает создатель языка K.
забыл совсем, у вас там скрол не работает в терминале :)
Rust с build.rs нервно курит в сторонке... Хотя, о чем это я. Для экспертов опеннета раст - не язык.
build.rs нужен в одном крейте из ста. Для обычной сборки обычного проекта на rust (с зависимостями, естественно) вообще ни строчки сборочной системы написать не надо.
а в чем проблема писать так чтобы одного языка хватало?
В том что одного не хватает?
> В том что одного не хватает?Зачем ты, дура, выбрала такой язык, которого тебе не хватает?
Кто-нибудь пробовал системы сборки meson или bazel?
Зависимости cmake весят больше программы в несколько раз. Прикольно, че.
смешнее то что куча из них (к счастью, не все - обязательные) давно сами без cmake не собираются.(поэтому у вас и не будет больше ни одной нормальной ос после линукса и венды)
Ну GCC вот тоже без GCC не собирается, и что?
А это очень неудобный вопрос!
Там вопрос не сформируется - рекурсия бесконечная.
вообще-то до недавнего времени собирался - причем чем-то уровня чуть ли не tinyc. Если даже поломали - ты все еще можешь им собрать 2.7.2 и последовательно доапгрейдиться до какой там тебе нужен для хеловротов.Именно благодаря этому у нас есть линукс. Потому что кросскомпилятором ты бы до сих пор что-то вроде хурда собирал.
> Если даже поломали - ты все еще можешь им собрать 2.7.2 и последовательно доапгрейдиться до какой там тебе нужен для хеловротов.Полагаю, с CMake можно поступить так же.
>> Если даже поломали - ты все еще можешь им собрать 2.7.2 и последовательно доапгрейдиться до какой там тебе нужен для хеловротов.
> Полагаю, с CMake можно поступить так же.нет, конечно. Потому что мильен зависимостей и пяток из них сами требуют cmake. Причем гвоздем прибита конкретная наираспоследняя версия (обычно если ее понизить этак на пяток ничего не ломается, но мы про новую ос а не портирование на freebsd7)
Так начиная со старой же.
> вообще-то до недавнего времени собирался - причем чем-то уровня чуть ли не tinycЛол, какой еще tinyc? 😂 С версии 4.8 (2013 год) GCC написан на C++.
значит, соберешь сперва 4.7
(Если тебе прям уперлось для твоей болгеносы наираспоследнюю версию компилятора)
это всяко попроще чем пытаться портировать наираспоследний компилятор на ос в которой еще ничего нет потому что нет компилятора.
даже больше, современному gcc нужен питон
> даже больше, современному gcc нужен питонну я собственно и говорил - повторить линукс не получится. Потому что "нужен пихон" а потом по зависимостям еще и хруст приедет. Со всеми тремя своими поддерживаемыми платформами - виндой, виндой, и еще, вот...
"Это какой-то позор..." (с)
Используй для таких программ обычный make
Смотри: https://www.opennet.dev/openforum/vsluhforumID3/137560.html#49
Автор забыл упомянуть, что CMake - это инструмент для тех, кто программирует на C++.
Для винды пользуюсь штатными *.vcxproj Студии и всё устраивает.
Для линукса пользуюсь штатными *.pro QtCreator'а и всё устраивает.
Все эти сборочные скрипты (make, cmake и т.п., тысячи их)... ни разу в жизни не понадобились, исключая только компиляцию исходников скачанных из инета. И то нередко такое бывает что скачаешь, а оно не компилируется.
> Для винды пользуюсь штатными *.vcxproj Студии и всё устраивает.
> Для линукса пользуюсь штатными *.pro QtCreator'а и всё устраивает.Ну а мог бы один раз под обе платформы написать CMkae файл. Ну и да, под Линуксом и Маком далеко не все проекты юзают QtCreator (именно для сборки).
> Все эти сборочные скрипты (make, cmake и т.п., тысячи их)... ни разу в жизни не понадобились
Это ровно до того момента, когда сборка проекта подразумевает что-то помимо компиляции C++ кода (т.е. когда у проекта кроме исполняемого есть и другие файлы). Вот тут на помощь как раз и приходят CMake и подобные, которые позволяют написать *всю* логику сборки один раз и под все платформы. Да, это логика все равно на опеределенный процент может быть специфичной для платформы, но главное что оставшаяся большая часть не дублируется в двух разных ".sh", ".bat" и т.п., да и сам "скрипт" является частью системы (и процесса) сборки.
> ... пользуюсь штатными *.pro QtCreator'аесть огромный шанс что в Qt 7 максимум 8 никакого *.pro не будет.
Никогда не понимал тех, кто билдит под линух и избегает мейк, если проект по сложности не ядро, то использование чего-то отличного от классического мейка неоправдано.
Это банальное неуважение к тем, кто возможно будет работать над такими проктами - порой доходит до абсурда - проект по сложности хеловрот какой нибудь, однако уже сборочного мусора натащено немало.