Сборка проекта на плюсах

Ну и что, что не напрямую? Тебе как разработчику что с того? Все равно ты можешь вызывать сборку через команду cmake --build и какая разница, что он там будет вызывать?

Cmake не помирает. Т.к. много разработчиков помимо указанных тобой проектов мспользуют cmake.

В том комменте нет нерешаемых проблем. А есть субъектианые хотелки.

Именно из-за их идиотских решений сегодня разработчики на C++ как последние виндузятники ползают по помойкам

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

Вот уж действительно. Не хотят страдать и пердолиться. Упыри какие-то.

Никто не заставляет страдать и пердолиться. Вакансий грузчиков полно.

https://www.codeblocks.org/ обсуждали? …

Так ползают типичные потребители

Нет, так ползают все пользователи CMake. В т. ч. и ЛОРовцы, которые имеют свои проекты, например, вот:

https://bitbucket.org/andreyu/simple-viewer-gl/src/master/cmake/

Поскольку CMake не предоставляет нормального решения для разрешения зависимостей, прикладным разработчикам приходится лазить по GitHub-помойками в Windows Way стиле, выискивая «нямку», то бишь FindModules.

А всё потому что CMake убог.

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

Ну давай, расскажи мне какие именно усилия к изучению инструмента Okteta мне нужно приложить, чтобы я мог редактировать или просто просматривать в нём файлы размером > 2 GiB, учитывая что:

Error – Okteta

Support to load files larger than 2 GiB has not yet been implemented.

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

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

Использую для своих проектов связку gn/ninja и другим рекомендую. Проблема может быть в том что gn не опакечен в вашем дистрибутиве. Тогда придется собирать самому.

например, вот:

Еще один не осилил pkg_check_modules. Все эти библиотеки предоставляют .pc файл в стандартной поставке. Значит, их тривиально импортировать в CMake без каких-либо сторонних инструментов. Если ты посмотришь содержимое файла FindLcms2 или FindWebp, там ровно это и делается. Исключением являются только FindImlib2 и clang-dev-tools. Первый писали под доисторический CMake, второй вообще не является Find*-файлом, и непонятно как там оказался.

Слабо, старайся лучше. Подсказываю: ты мог бы рассказать о том, что в meson fallback на pkgconfig встроен по умолчанию.

приходится лазить … выискивая «нямку»

Все начинается с того, что они используют сторонние библиотеки. Надо все делать самому, нет библиотек – нет зависимостей.

не смогли завезти хоть сколько-нибудь адекватный HEX-редактор

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

и много ты сам сделал

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

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

и много ты сам сделал

На github много хороших и СУПЕР ХОРОШИХ проектов /конечно и мусора МНОГО/.

Работа трудная, но нужная - найти github хорошие проекты и попросить разработчиков дистрибутивов их добавить … /о многом не сказал конечно/ …

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

premake говно

и вообще систему сборки отличимую от языка разработки, я бы не рассматривал вообще

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

Все начинается с того, что они используют сторонние библиотеки.

Так и запишем: CMake дно, если проект не Hello World без зависимостей.

Надо все делать самому, нет библиотек – нет зависимостей.

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

поцык который пишет гуи формочку к которой прикручивает +10500 готовых библиотек для распаковки и просмотра этих форматов изображений - ГОВНОКОДЕРОК

интересно, нытье про сборку cmake-проектов с SDL2 - это, типа, серьезно? https://github.com/xyproto/sdl2-examples/tree/main/c%2B%2B20-cmake - первый же нагугленный за минуту пример, прекрасно компиляется и показывает картинку с недовольным котом при запуске.

Может, это не в cmake проблема, а в том что кто-то не умеет программировать?

Еще один не осилил pkg_check_modules

Linus Torvalds тоже не осилил CMake, он использует Makefile и не знает проблем.

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

Таким был autocraptools, таким является и CMake. Да, в последних версиях он стал чуть лучше и более человечнее, но за тот адок что был в 2.8, за упоротый на голову DSL, за виндовую регистронезависимость и за другую хрень вроде того что DSL помещается не в файлы собственным расширением по типу Build.cmake, а в якобы текстовые CMakeLists.txt которые на самом деле DSL, из-за чего куча разных редакторов не может их нормально подсветить, за всё это нужно бойкотировать этот CMake везде где только можно, чтобы этот рак не пустил метастазы, как уже пустил их autotools.

И Red Hat, к счастью, один из немногих кто сделал ставку не на этот ужас.

тупой торвальдс даже С++ не осилил

куда там ему cmake

все ядро в одних goto и unlike

Где можно почитать 500-страничные талмуды про обход кучи проблем в автотулзах? Не знаю про такие. У тебя конечно же будут ссылки.

Linus Torvalds тоже не осилил CMake, он использует Makefile и не знает проблем.

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

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

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

предполагает кучу пердолинга вместо того, чтобы делать элементарные вещи

В том-то и дело, что нет «кучи пердолинга».

он стал чуть лучше и более человечнее,

Он стал значительно лучше и многократно человечнее. Старый CMake, с его include’ами, теперь считается антипаттерном.

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

Бойкотировать следует meson, пока их официальная реализация не будет переписана с python на настоящий ЯП.

Старый CMake, с его include’ами, теперь считается антипаттерном.

О, значит на горизонте замаячила ещё одна проблема предполагающая сломанную обратную совместимость в будущем и чтение многостраничных талмудов на тему что именно там теперь эти наркоманы считают антипаттерном при попытках перетянуть какое-нибудь Legacy с 2.8 на новый CMake который «не совсем такое говно как старый».

Бойкотировать следует meson, пока их официальная реализация не будет переписана с python на настоящий ЯП.

Абсолютно всё лучше чем наркоманский DSL этого CMake, за исключением разве что Bash и M4 дрисни из craptools. Чёрт возьми, даже сборочная система используящая для описания сборки скрипты на PHP была бы на голову адекватнее этой уродливой недолиспоподелки.

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

Похвально, что будучи сторонником CMake ты осознаёшь что эта проблема существует и почему разработчики столкнувшись с ним разок-другой (особенно в реинкарнации 2.x) не бегут его выбирать для своих проектов.

redo - из чисто эстетических соображений )

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

Старое было плохим – а новое не сметь делать лучше. Замечательная позиция.

Бойкотировать следует meson, пока их официальная реализация не будет переписана с python на настоящий ЯП.

Абсолютно всё лучше чем наркоманский DSL этого CMake […]

При чем тут DSL? Я указываю на язык, на котором написана реализация системы сборки. Язык meson’овского DSL питоном не является, хотя и очень похож.

В cmake раздражает отсутствие поддержки нескольких тулчейнов в одном проекте. Китваровцы говорят используйте externalproject. Но это ж форменное уродство.

В обычном make или ninja такого ограничения нет. В meson дело обстоит лучше, в проекте можно использовать два тулчейна, target и native.

а в якобы текстовые CMakeLists.txt которые на самом деле DSL, из-за чего куча разных редакторов не может их нормально подсветить

Что за редакторы и кто им мешает подсвечивать?

И Red Hat, к счастью, один из немногих кто сделал ставку не на этот ужас.

А meson.build это другое?

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

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

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

А meson.build это другое?

Конечно, ведь это не файл с расширением .txt, от которого ожидается Plain Text. А CMake помещает свой наркоманский DSL в .txt файл. При этом другие CMake-файлы, вроде FindModules имеют нормальное расширение .cmake

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

Ну а case-insensitive это прямо вишенка на этом говнявом торте. Помимо всех архитектурных проблем, которыми кишит CMake, им даже чисто эстетически пользоваться противно: регистронезависимость прямиком по традициям винды, когда в разных проектах по разному определено:

TARGET_LINK_LIBRARIES(program mylib)
target_link_libraries(program mylib)
Target_Link_Libraries(program mylib)
Target_link_libraries(program mylib)

А то и в одном и том же проекте или даже файле.

Старое было плохим – а новое не сметь делать лучше. Замечательная позиция.

Ой, а зачем они тогда в файл описания сборки минимальную версию помещают? Получается она теперь точно такая же фикция, как и их первоначальная инициатива по распространению FindModules внутри дистрибутива CMake, которую они не осилили и развели на GitHub’е вот эту помойку: https://github.com/search?q=extension%3Acmake+filename%3AFind*&type=Code&ref=advsearch&l=&l=

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

При чем тут DSL? Я указываю на язык, на котором написана реализация системы сборки. Язык meson’овского DSL питоном не является, хотя и очень похож.

Проблема языка на котором написана реализация системы сборки, намного менее значимая чем проблема наркоманского недолиспоподобного DSL. Ей-богу, лучше бы вместо CMake DSL там был интерпретатор Lisp’а или какого-нибудь его декларативного диалекта, было бы куда функциональнее и удобнее абсолютно всем.

с каких это пор cmake toolchain file не работает ?

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

Да, и это точно не название файла CMakeLists.txt

Конечно, ведь это не файл с расширением .txt, от которого ожидается Plain Text. А CMake помещает свой наркоманский DSL в .txt файл.

Я все равно не понимаю. Если редактор не поддерживает синтаксис CMake, то CMakeLists.txt отобразится как plain text, в чем проблема? Кстати, а что ожидается от файла с расширением .build и как редактор должен такой файл раскрасить? Я надеюсь, ты понимаешь, что тот же meson.build распознается не из-за расширения .build. Где здесь разница с CMake? И что насчет meson_options.txt?

А существуют ли какие-нибудь варианты, если я хочу положить на всю эту кроссплатформенность, остановитью лишь на юникс-подобных ос. В принципе (сейчас скажу страшное) иделаьно смотрится autoconf + обычные make файлы, на помойку идут все эти безумные абстракции, всё упрощается. Но хотелось бы чтобы билд система дружила с cmake’ом - могла клепать его config файлы. Может есть варианты? Или можно научить этому autoconf (из коробки работающее, а не через написание руками каких-нибудь шаблонов)?

Ой, а зачем они тогда в файл описания сборки минимальную версию помещают?

Чтобы указать минимальную версию?

Получается она теперь точно такая же фикция

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

При чем здесь обратная совместимость? Развитие CMake происходит путем добавления и постепенного включения «политик». Минимальная версия CMake определяет набор политик «по умолчанию». Старые скрипты могут сломаться на новых версиях CMake, и для их починки достаточно отключить ломающие их политики. cmake_minimum_required это обертка над cmake_policy, с помощью которой можно указать минимальную и максимальную версию CMake, под которую написан данный скрипт.

и их первоначальная инициатива по распространению FindModules внутри дистрибутива CMake, которую они не осилили и развели на GitHub’е вот эту помойку: https://github.com/search?q=extension%3Acmake+filename%3AFind*&type=Code&ref=advsearch&l=&l=

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

Проблема языка на котором написана реализация системы сборки, намного менее значимая чем проблема наркоманского недолиспоподобного DSL

Это субъективная оценка. Я считаю проблему языка значительно более важной. DSL наркоманский, но ничего сложного в нем нет, если есть навыки писать на условном bash.

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

ну а что, сам то на крестах конпелируешь свой проект?

что в этой ветке форума делают анонизные говноделы которые к с++ никакого отношения не имеют ?

Он хоть до сих пор мейнстрим (вроде как), но мой опыт это сплошная попа-боль и, вроде как, тут многие не любит CMake.

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

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

Промышленный стандарт это CMake. А так — лично мне удобней обычный make, для пет проектов так и делаю.

я тоже лет 10 назад делал мейки

пока проекты не стали кросс платформенные

Автотулзы для копрофагов.

ребята, пусть будет и make и Cmake. дайте выбор людям. кому-то удобнее make а кому-то Cmake. зачем пытаться самолет заменить вертолетом!

Это примерно как с си и ассемблером. Из компилятора си до сих пор можно при желании выгнать ассемблерный листинг. Вот и cmake на выходе из себя низкоуровневый Makefile выгоняет. Но есть и разница: из компилятора си можно получать ассемблер, а можно не получать. А вот с cmake путь только один, через две ступени.

Но я не против выбора, выбор пусть будет.

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

выгнать

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

выбор пусть будет.

ну если только на словах. на деле его не будет никогда.

какое интересное слово. оно у нас воглаве всего.

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

лично я сmake не очень

Я тоже. Просто пока получается, что «остальные ещё хуже».

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

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

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

В винде только Симейк нужно ставить, без make, во всяком случае если собирать под msvs, сmake сгенерит файл «решения», который откроется в Студии.