Представлен релиз кроссплатформенного открытого генератора сценариев сборки CMake 4.0.0, выступающего в качестве альтернативы Autotools и используемого в таких проектах, как KDE, LLVM/Clang, MySQL, MariaDB, ReactOS и Blender. Код CMake написан на языке C++ и распространяется под лицензией BSD...Подробнее: https://www.opennet.me/opennews/art.shtml?num=62974
Какие преимущества перед Мизоном?
Распространённость и... и всё.
Преимущества что в отличии от мизона смаке легко пользоваться.
Я бы не сказал что cmake прост в использовании
У него отличная документация, в отличие от...
> Преимущества что в отличии от мизона смаке легко пользоваться.И еще - не на питоне дурацком, так что не выдвигает требований по (не)совместимости :)
Что любопытно пакетный менеджер Conan для C и C++ написан и... версии 1 и 2 несовместимы. Микрософт написали vcpkg на обычном CMake поэтому таких проблем нет при обновлениях.
> Что любопытно пакетный менеджер Conan для C и C++ написан и... версии
> 1 и 2 несовместимы. Микрософт написали vcpkg на обычном CMake поэтому
> таких проблем нет при обновлениях.Виндопроблемы такие виндопроблемы. В линухе это все проще, apt install libsomething-dev и в обшем то весь пакетный менеджмент для сей. А в винде все как всегда...
Мезон под гномом, сабж под вендузятниками.
> Мезон под гномом, сабж под вендузятниками.Поэтому они / в путях юзали? Странные какие-то виндузятники. А гномеры наверное даже хуже виндузятников, вообще пытаются мобилку из десктопа делать. До этого даже MS не допер.
Обратная косая только в досе, ничего странного.
DOS прекрасно понимает пути с обычными слэшами.
а ты DOS с его эмулятор в винде не путаешь?
Было такое называется Windows 8. В Windows 8.1 по просьбе не довольных вернули некоторые вещи обратно. "Windows 8 была разработана с учетом как мобильных устройств, так и настольных компьютеров. Она представила новый интерфейс, известный как "Metro" (позже переименованный в "Modern UI"), который был оптимизирован для сенсорных экранов и мобильных устройств, таких как планшеты.Windows 8 также поддерживала традиционный рабочий стол, что позволяло пользователям с настольными компьютерами и ноутбуками продолжать использовать привычные приложения и интерфейс. Однако переход к новому интерфейсу и изменения в пользовательском опыте вызвали смешанные отзывы, и многие пользователи предпочли более традиционный интерфейс, который был в Windows 7.
В результате, Microsoft учла отзывы пользователей и внесла изменения в Windows 8.1, а затем вернулась к более привычному интерфейсу в Windows 10"
> Было такое называется Windows 8. В Windows 8.1 по просьбе не довольных
> вернули некоторые вещи обратно. "Windows 8 была разработана с учетом как
> мобильных устройств, так и настольных компьютеров.Это чего туда "вернули"? Тупое полноэкранное меню пуск или дурацкие HTML5 плитки - вместе с ВТОРЫМ набором системных настроек, отдельным от первого?
> как "Metro" (позже переименованный в "Modern UI"), который был оптимизирован для
> сенсорных экранов и мобильных устройств, таких как планшеты.Поэтому на обычном десктопе UX стал пробивать дно - и пользователи ее искренне ненавидели. Да и в десятке 50/50. А потом я и не следил. Слышен какой-то писк про AI в блокноте, кейлогеры, рекламу и онлайнакаунты. Моя точка зрения? "Хорошо что все это не у меня!" :)
> В результате, Microsoft учла отзывы пользователей и внесла изменения в Windows 8.1,
> а затем вернулась к более привычному интерфейсу в Windows 10"Мне, к счастью эти отношения жаб и гадюк уже сильно пофиг.
Скорее интересны преимущества перед premake, xmake, scons и waf
эти все какая-то маргинальщина, в основном же юзают мизон и смаке в открытых проектах
Gn всё ещё самый популярный и наиболее распространённый в опенсорсе.
это GNиль от гулгла которая? ни справки, ни разобраться?
> Скорее интересны преимущества перед premake, xmake, scons и wafВ отличие от этой неведомой фигни он не является маргинальщиной и используется кучей проектов. Нормальное преимущество - "не надо изучать маргинальную фигню".
Прикасался к каждой хтони в разное время.premake - lua-подобный синтаксис, по ощущениям - просто надстройка над make, которая описывает сборку, только иначе. Наверное, ее писали lua-шники, которые не осилили сам make. Винить в этом их не стоит.
xmake - система сборки, которая написана другими lua-шниками (серьезно, ребята, вам делать нечего?). В отличие от premake, эти ребята упоролись в декларатизм, и работает это, на удивление, лучше.
scons и его прарадитель cons - это детище питонистов, которые на DSL вообще болт клали, и пишут систему сборки как программу на питоне. Питон их, собственно, и похоронил.
waf - а вот ее писали те питонисты, которым не понравился scons (видать, синдром "написано не мной" - заразная хворь, что у луашников, что у питонистов). Декларативный стиль наконец появился, но все косяки и болезни scons никуда не делись.
Завершая экскурс в историю, скажу, что cmake на голову обходит всех их, а на момент появления каждой из них был вообще на две головы выше. Зачем было тратить столько ресурсов на тупиковые направления - загадка. Видимо, природа такая человеческая - тратить своё время на бесполезные занятия.
Преимущество в том что CMake все поддерживают и он становится некоторым де-факто стандартом для C++, а самое важное его поддерживает vcpkg и теперь охренелион зависимостей в проект можно подтянуть двумя файлами.
и пакетный менеджер Conan продвигаемый JFrog, но обновления принимают там намного дольше
meson не поддерживает и не будет никогда поддерживать
C++ модулиhttps://github.com/mesonbuild/meson/issues/11256
>C++20 modules #11256
>Closed as not planned
Это какой-то левый тикет. Основное обсуждение вот https://github.com/mesonbuild/meson/issues/5024 . Читал я, правда, по диагонали, но не увидел мысли> meson не поддерживает и не будет никогда поддерживать
Как я понял от одного из разработчиков в треде
```
The current status is that basic cases should mostly work. I have been working on fixing up our scanner and how we do scanning to get faster and more accurate results see here, mainly aiming at Fortran since they've hod modules longer, and C++ and Fortran modules have many of the same design decisions.
```они над этим работают, но пока ещё рано выпускать в люди.
Например в симейк не нужно программировать отдельно поддержку библиотеки как в мезоне:https://github.com/mesonbuild/meson/blob/19482e4553775d4612f...
> Например в симейк не нужно программировать отдельно поддержку библиотеки как в мезоне:
> https://github.com/mesonbuild/meson/blob/19482e4553775d4612f...Так это же обёртки для удобства. И не над библиотекой, а над Гномовскими генераторами кода. Не, ну, можно и врукопашную с custom_target/run_target-ами сношаться (прямо, как в cmake), кто-бы был против. Но с обёртками всё-таки удобнее.
>> Например в симейк не нужно программировать отдельно поддержку библиотеки как в мезоне:
>> https://github.com/mesonbuild/meson/blob/19482e4553775d4612f...
> Так это же обёртки для удобства. И не над библиотекой, а над
> Гномовскими генераторами кода. Не, ну, можно и врукопашную с custom_target/run_target-ами
> сношаться (прямо, как в cmake), кто-бы был против. Но с обёртками
> всё-таки удобнее.Ну-ну. Удобство это конечно хорошо, в принципе. Но тогда выходит, если не запихать поддержку особенностей библиотеки прямо в исходники, то Мезон внезапно станет неудобным? А ты считаешь нормальным пихать поддержку какой-то библиотеки в систему сбоки? И что, каждая библиотека будет добавлять свою простынку нечитаемого кода прямо в исходники Мезона или разрабы Мезона будут решать, какая библиотека заслужила эту привилегию, а какая нет?
Ну уж нет, спасибо, я лучше custom_target-ы попишу.
> Ну-ну. Удобство это конечно хорошо, в принципе. Но тогда выходит, если не
> запихать поддержку особенностей библиотеки прямо в исходники, то Мезон внезапно станет
> неудобным?Нет. Просто ты вернёшься в те же custom_target-ы. Можешь не пользоваться модулем GNOME, если желаешь, кто же тебе возразит-то.
> А ты считаешь нормальным пихать поддержку какой-то библиотеки в систему
> сбоки?Ещё раз: это НЕ поддержка библиотеки, это сахарок для задействования автогенераторов (glib-mkenums, g-ir-scanner, gdbus-codegen и вот этого всего), которые генерируют boilerplate-код в рамках GObject (если эти генераторы вообще в проекте задействованы, что не факт), чтобы не городить CT-ы, а просто вызывать их, как объекты/зависимости.
Библиотеку можно подключать, как обычное dependency. Модуль для этого НЕ нужен.
> И что, каждая библиотека будет добавлять свою простынку нечитаемого кода
> прямо в исходники Мезона или разрабы Мезона будут решать, какая библиотека
> заслужила эту привилегию, а какая нет?Ну, разрабы GNOME-а вот запилили, чтобы было удобно. Разрабам meson-а зашло. Мне тоже, например.
> Ну уж нет, спасибо, я лучше custom_target-ы попишу.
Ну, пиши, кто ж запрещает-то.
> ты вернёшься в те же custom_target-ы Можешь не пользоваться модулем GNOME, если желаешь, кто же тебе возразит-то.Ну давай, покажи как собрать без этого костыля. А то может и нельзя собрать ничего. Даже скорее всего.
>> А ты считаешь нормальным пихать поддержку какой-то библиотеки в систему
>> сбоки?
> Ещё раз: это НЕ поддержка библиотеки, это сахарок для задействования автогенераторов (glib-mkenums,
> g-ir-scanner, gdbus-codegen и вот этого всего), которые генерируют boilerplate-код в
> рамках GObject (если эти генераторы вообще в проекте задействованы, что не
> факт), чтобы не городить CT-ы, а просто вызывать их, как объекты/зависимости.g-ir-scanner, gdbus-codegen и "вот этого всё" это особенности этой конкретной библиотеки.
Сахарок, это когда улучшают синтаксис для всех. А это нахывается костыль. Костыль для Гнома. Не, простите, не костыль. КОСТЫЛИЩЕ
Это даже не компилятор, это просто какие-то генераторы и другие приблуды этой конкретной библиотеки. Но вообще-то генераторы кода это не что-то уникальное, а встречается достаточно часто. Даже в моих проектах такое есть. И что, они разрабы мезона добавят поддержку моего генератора для моего проекта? Ответ очевиден.
> Библиотеку можно подключать, как обычное dependency. Модуль для этого НЕ нужен.Прям от сердца отлегло, ну спасибо и на том. А как же тогда генерировать код этими генераторами? Или там ненужный код генерируется. ;)
>> И что, каждая библиотека будет добавлять свою простынку нечитаемого кода
>> прямо в исходники Мезона или разрабы Мезона будут решать, какая библиотека
>> заслужила эту привилегию, а какая нет?
> Ну, разрабы GNOME-а вот запилили, чтобы было удобно. Разрабам meson-а зашло. Мне
> тоже, например.Да конечно удобно. Чего стараться, придумывать какой-то язык, какие-то универсальные способы для расширения для всех, когда можно прямёхонько в код воткнуть поддержку Гнома. Удобно же! А что, разрабам зашло ведь :)
Ну так такие разрабы, раз им такое заходит. Как по мне, студентов за это надо бить по рукам. Очень сильно. Но если такое нужно объяснять зрелым разработчикам, то извините.
> Ну давай, покажи как собрать без этого костыляСоздаёшь custom_target -> пихаешь туда приложение/набор ключей/INPUT - исходник/OUTPUT -кортеж нагенерированного -> вписываешь CT в зависимость target-а. Всё.
До этого, правда, не забываешь проверить, установлено-ли у тебя вообще это приложение и прочая тряхомудь с проверками и вспоминанием ключей. Вот это всё, благодаря модулю, ты делаешь ОДНОЙ командой. Если не хочешь делать так - делай, не пользуйся модулем, если ты его так не любишь.Таких врапперов написан и для CMake-а дохрена и больше, к слову.
> g-ir-scanner, gdbus-codegen и "вот этого всё" это особенности этой конкретной библиотеки.
Из всего текста ниже понятно, что под GObject/Gtk ты не писал примерно никогда, но мнение имеешь.
> И что, они разрабы мезона добавят поддержку моего генератора для моего проекта?
Будут по популярности сопоставимы с Gtk/Qt - добавят.
> Чего стараться, придумывать какой-то язык, какие-то универсальные способы для расширения для всех
Модули и сделали затем, чтобы НЕ пихать их в основной DSL. НЕ надо, НЕ пользуешься.
К слову, давно-ли ты что-то делал на Qt/Gtk и собирал это CMake-ом? Хотелось-ли тебе пристрелить его авторов? Мне - да.> Ну так такие разрабы, раз им такое заходит. Как по мне, студентов за это надо бить по рукам. Очень сильно.
Вот таких ваших студентов потом на работу и не берёт никто.
> Создаёшь custom_target -> пихаешь туда приложение/набор ключей/INPUT - исходник/OUTPUT -кортеж нагенерированного -> вписываешь CT в зависимость target-а. Всё.Не верю! Было бы всё так просто, никто бы не вкорячивал 2200 строк нечитабельного кода в исходники мезона. Либо это не будет работать вообще, либо это будет работать коряво и плохо отслеживать зависимости, либо ещё чего-то.
> Из всего текста ниже понятно, что под GObject/Gtk ты не писал примерно никогда, но мнение имеешь.
Писал очень давно, больше на жткмм и задолго до того, как появился мезон. Но какое это имеет отношение? Универсальная система сборки (или та, которая на это претендует) должна предоставлять инструменты для разработчиков библиотек, а не носить код для каждой библиотеки в исходниках. И не важно, писал ты для какой-то очередной библиотеки или нет.
Вот если бы этот модуль можно было предоставить прямо вместе в Гномом, который подключался бы в в виде плагина к мезону, то тогда ладно ещё. Каждый разработчик библиотеки мог бы написать такой плагин для своей библиотеки. А так это обыкновенный костыль (длиной в 2200 строк нечитабельного кода), который прикрывает срамоту - проблемы с самим мезоном.
> К слову, давно-ли ты что-то делал на Qt/Gtk и собирал это CMake-ом? Хотелось-ли тебе пристрелить его авторов? Мне - да.
В симейке поддержка кют меня устраивает, но в симейке она тоже прибита гвоздями в коде, хотя его там и немного. Это, разумеется, тоже небольшой костыль. На жтк и его поддержку в симейк не смотрел.
> Не верю!Верующим людям в IT, инженерии и много где ещё НЕ место!
Вывод о том работает это и ли нет, как и оценки качества работы, выполняется на расчётах, экспериментах и тестах, которые можно воспроизвести и перепроверить, а не на основании вашей веры.
>> Не верю!
> Верующим людям в IT, инженерии и много где ещё НЕ место!
> Вывод о том работает это и ли нет, как и оценки качества
> работы, выполняется на расчётах, экспериментах и тестах, которые можно воспроизвести и
> перепроверить, а не на основании вашей веры.Ну так приведи эксперименты и тесты. Пока что всё, что я увидел, это что в исходники Мезона вкорячена поддержка Гнома. Это факт.
Утверждение что это всё "вспомогательное" и без этого можно легко обойтись ничем не подкреплено кроме слов собеседника, я очень сильно сомневаюсь что разработчики Мезона допустили бы такое без крайней на то нужды. Может быть это конечно правда, но я очень сильно сомневаюсь. Извиняюсь если кого-то это задело.
В любом случае, даже если это правда и без этого можно обойтись, это не отменяет изначальный архитектурный косяк - в "универсальную" систему сборки вкорячена поддержка Гнома.
> К слову, давно-ли ты что-то делал на Qt/Gtk и собирал это CMake-ом?
> Хотелось-ли тебе пристрелить его авторов? Мне - да.Постоянно собираю Qt-шные проекты CMake-ом, пока все живы. Недавно делал CMake для сборки приложения с Qt4/5/6, вот там пришлось немного повозиться, но тоже ничего криминального.
> Модули и сделали затем, чтобы НЕ пихать их в основной DSL. НЕ
> надо, НЕ пользуешься.Просто представь что в make бы впендюрили поддержку каких-нибудь популярных либ тех лет, например Motif и Turbo Vision, типа что тут такого, "НЕ надо, НЕ пользуешься".
> Просто представь что в make бы впендюрили поддержку каких-нибудь популярных либ тех
> лет, например Motif и Turbo Vision, типа что тут такого, "НЕ
> надо, НЕ пользуешься".Угу. make-у для этого аж целый autotools наваяли, заменой которого meson и является. А в роли make, внезапно, выступает ninja, синтаксис которой на порядок проще.
>> Просто представь что в make бы впендюрили поддержку каких-нибудь популярных либ тех
>> лет, например Motif и Turbo Vision, типа что тут такого, "НЕ
>> надо, НЕ пользуешься".
> Угу. make-у для этого аж целый autotools наваяли, заменой которого meson и
> является. А в роли make, внезапно, выступает ninja, синтаксис которой на
> порядок проще.autotools, внезапно, расширяем на стороне пользователя, в него поддержка библиотек гвоздями не прибита
> autotools, внезапно, расширяем на стороне пользователя, в него поддержка библиотек гвоздями не прибитаТы, видимо, до сих пор не догоняешь что это хелперы, для утилит GObject (которые могут и не использоваться), а не ПОДДЕРЖКА БИБЛИОТЕКИ (tm).
Библиотеки стандартно meson резолвит через pkg-config (опционально через cmake). Модули для этого не нужны.```
deps = [
dependency('glib-2.0'),
dependency('gobject-2.0'),
dependency('gtk+-3.0'), # ну или какое там тебе надо
]app = executable (
...,
dependencies: deps,
...
)
```Всё что надо для подключения всего стека Gtk, чтобы создать приложение. Опционально, в свойствах депсов можно указать диапазон версий и обязательность. Никакие модули не нужны. Что ещё непонятного?
>> autotools, внезапно, расширяем на стороне пользователя, в него поддержка библиотек гвоздями не прибита
> Ты, видимо, до сих пор не догоняешь что это хелперы, для утилит
> GObject (которые могут и не использоваться), а не ПОДДЕРЖКА БИБЛИОТЕКИ (tm).утилиты
>[оверквотинг удален]
> ]
> app = executable (
> ...,
> dependencies: deps,
> ...
> )
> ```
> Всё что надо для подключения всего стека Gtk, чтобы создать приложение. Опционально,
> в свойствах депсов можно указать диапазон версий и обязательность. Никакие модули
> не нужны. Что ещё непонятного?
>> autotools, внезапно, расширяем на стороне пользователя, в него поддержка библиотек гвоздями не прибита
> Ты, видимо, до сих пор не догоняешь что это хелперы, для утилит
> GObject (которые могут и не использоваться), а не ПОДДЕРЖКА БИБЛИОТЕКИ (tm).Какая разница, хелперы, не хелперы? Это что, ненужные утилиты GObject, которые можно выбросить? Может патч предложишь по их выкидыванию? Ах нужные? А для чего они нужны, кроме библиотеки Gnome? Ах, только для Gnome?
Вот это и называется ПОДДЕРЖКА БИБЛИОТЕКИ (tm).
> Какая разница, хелперы, не хелперы?Мне действительно жалко студентов. С такими преподавателями они-же оптом пополнят штат дворников местного ЖЭК-а.
> Это что, ненужные утилиты GObject, которые можно
> выбросить? Может патч предложишь по их выкидыванию? Ах нужные? А для
> чего они нужны, кроме библиотеки Gnome? Ах, только для Gnome?Понятно, что Gtk ты не знаешь. Но чушь пороть не перестанешь.
> Вот это и называется ПОДДЕРЖКА БИБЛИОТЕКИ (tm).
Сам определение придумал, сам себе доказал. Удобно. Я точно должен в этом процессе участвовать?
Вопрос: на прекрасном, с твоей точки зрения, диалекте cmake ты эти утилиты (половина из нх вообще скрипты, но пофиг) будешь использовать как? Чур CT/RT не использовать. Это же не "поддержка библиотеки", по твоим же словам.
Отдельно будет смешно потом эту портянку засунуть в зависимость и собрать meson через модуль-транслятор cmake (тоже модуль, прикинь). С большой долей вероятности оно сконвертирует CMake AST в код meson и соберёт.
upd: Для autotools, к слову, такие же расширения были написаны, теми же проектами.
> Понятно, что Gtk ты не знаешь. Но чушь пороть не перестанешь.Я никогда не утверждал что я спец по Жтк, немного имею представление, не больше. Но я не поленился и почитал что делают эти хелперы. В одном месте Мезон генерирует хедеры и исходники для подключения ресурсов в бинарник (gnome.compile_resources). Другой (gnome.generate_gir) генерирует файлы интроспекции для биндинга других языков. Третий генерирует поддержку енумов и т.д. и т.п. - их там десяток. Всё это естественно вполне необходимо и реально используется для сборки многих гномовских приложений, без этого они просто не соберутся.
То есть факт остаётся фактом - в Мезоне прибита гвоздями поддержка Гнома.
> Вопрос: на прекрасном, с твоей точки зрения, диалекте cmake ты эти утилиты
> (половина из нх вообще скрипты, но пофиг) будешь использовать как? Чур
> CT/RT не использовать. Это же не "поддержка библиотеки", по твоим же
> словам.Я никогда не интересовался, как это делается в симейке, потому что не разрабатываю приложений с использованием Гнома. Но это несложно нагуглить - в симейке нет встроенной поддержки и это всё пишется на их языке и будет выглядеть как обёртка для вызова утилит (или мезона) для генерации исходников, типа
find_program(GIR_SCANNER g-ir-scanner)
find_program(GIR_COMPILER g-ir-compiler)add_custom_command(
OUTPUT MyLib-1.0.gir
COMMAND ${GIR_SCANNER}
--namespace=MyLib
--nsversion=1.0
--library=my_lib
--include=GObject-2.0
--output=MyLib-1.0.gir
${CMAKE_CURRENT_SOURCE_DIR}/mylib.h
DEPENDS my_lib
)add_custom_command(
OUTPUT MyLib-1.0.typelib
COMMAND ${GIR_COMPILER} MyLib-1.0.gir -o MyLib-1.0.typelib
DEPENDS MyLib-1.0.gir
)Наверняка есть и готовые модули для этого, которые можно просто скачать и подключить. Правильно ли это? Да, правильно. Достаточно ли хорош язык симейк для поддержки этого всего - не знаю, не пробовал. Но это правильный путь развития, верное архитектурное решение.
> upd: Для autotools, к слову, такие же расширения были написаны, теми же
> проектами.Ты пойми, проблема не в том, что разработчики Мезона написали модуль для поддержки Гнома, а в том как они это сделали. Они не добавили в Мезон возможность написания расширений или плагинов типа этого для разных библиотек, а просто вкорячили поддержку Гнома напрямую в исходники Мезона.
Аутотулс, при всей его сложности и замысловатости, предельно гибок, расширяем и в него можно добавить поддержку любой библиотеки. Точно так и в Симейк, худо-бедно и с матюками можно расширить и написать поддержку для нужной библиотеки. В Базеле тоже можно. Но в Мезон это сделать невозможно на сегодняшний день, он не поддерживает расширения или плагины и поэтому поддержку Гнома в него всунули прямо в исходники.
С точки зрения архитектуры это полный зашквар. Ногоу. Катастрофа. Трындец.
Мезон наверное хорошая система сборки для Гнома. Но как универсальная система увы, пока ещё не дорос.
```
gir_scanner = find_program('g-ir-scanner', required : true)
gir_compiler = find_program('g-ir-compiler', required : true)ct_gscan = custom_target('gir_scan',
command:[gir_scanner,
'--namespace=MyLib',
'--nsversion=1.0',
'--library=my_lib',
'--include=GObject-2.0',
'--output=@OUTPUT@',
@INPUT@],
output: 'MyLib-1.0.gir',
input: 'mylib.h',
depends: my_lib)ct_gbuild = custom_target('gir_build',
command: [gir_compiler,
@INPUT@, '-o', @OUTPUT@
],
output: ' MyLib-1.0.typelib',
input: 'MyLib-1.0.gir',
depends: ct_gscan)
```Вот тот-же самый спич на DSL meson (пишу с телефона, поэтому плюс-минус). Можно вместо простой и лаконичной команды встроенного модуля писать и так.
Как-то так, короче https://mesonbuild.com/Generating-sources.html
По поводу внешних модулей - очень спорный плюс. Они есть у cmake - ну и по результату, сколько полу(не-)рабочего хлама среди тех модулей? Как по мне, сразу описать вместе с библиотекой правила сабпроджекта проще. Или вот, как в данном случае, модуль расширения, но который гарантировано работает.
> По поводу внешних модулей - очень спорный плюс. Они есть у cmake
> - ну и по результату, сколько полу(не-)рабочего хлама среди тех модулей?Наверняка есть нерабочее, но в чём проблема - поставляешь со своим приложением или библиотекой рабочее. В этом и прелесть внешних модулей. Что-то идёт прямо с симейк, что-то с библиотекой, но ты всегда можешь написать что-то своё или скачать где-нить альтернативу. Как жить без этого не знаю. Ну разве что пхать всё в исходники системы сборки или каждый раз копировать из подпроекта в подпроект и в другие проекты...
> Или вот, как в данном случае, модуль расширения, но который гарантировано
> работает.Это КОСТЫЛИЩЕ, фу, кака, так нельзя. Ладно, всё ясно, пошли уже по кругу...
CMake давно пора заменить нейросетям. И описаниями на естественном языке.
Сразу всеми нейросетями заменить точно , что бы одна кнопка и готово. А , ты умный! Тоже так же думаю!
Вы понимаете что выполнение задач нейросетями не детерминировано?
>сделать за*****Да?
Для всех хейтеров CMake: если вы считаете, что новый релиз 4.0.0 не изменит ваше негативное мнение, то, вероятно, вы просто не обновили свои навыки разработки со временем. Ну что ж, оставайтесь в прошлом с вашими устаревшими привычками, в то время как другие двигаются вперед, используя современные инструменты для улучшения своей работы. Всегда найдется место для прогресса, даже если для некоторых он кажется чуждым.
Ути-пуся, уже делаются тулы _лучше_ cmake ... и когда их таки доведут до ума ...
(подставь сюда свой текст. :)
Ну, конечно, всегда есть место для улучшений и конкуренции. Если новые тулы действительно обещают быть лучше, то это замечательно! Но не забывайте, что CMake уже давно зарекомендовал себя как надежный инструмент среди многих разработчиков. Пока ждем, когда эти 'тулы' доведут до ума, CMake продолжает помогать множеству проектов достигать успеха. Конкуренция всегда стимулирует инновации, так что будем следить за развитием событий!
Вырвиглазное ничто этот ваш cmake, но в мире C++ стал почему-то почти стандартом
А какая альтернатива? Автокрап?
Bazel уделывает cmake по всем параметрам
> Bazel уделывает cmake по всем параметрамJava - сразу мимо!
Есть реализация на Rust
Ещё мимей.
А он умеет собирать Cxx проекты?
По параметрам жрущести и безопасности бизнеса (чтобы всякие васяны не лезли в проекты своими грязными лапами) точно.
> Bazel уделывает cmake по всем параметрамВ смысле, по ненужности чтоли? Жуткий гуглокрап, настолько ужасный что используется только гуглем по сути, обвешаный питоном и жабой, так что при попытке что-то ЭТИМ собрать - качается полинтернета.
Visual Studio проекты))) или на худой конец QtCreator, CodeBlocks))). Наглядно и сердито)))
Но QtCreator это IDE и он пользуется для сборки, всё тем же, cmake. Или альтернативно может QBS.
Наглядно, сердито, но что делать на системах без GUI, таких как CI?
> Вырвиглазное ничто этот ваш cmake, но в мире C++ стал почему-то почти стандартомОчень аккуратное отношение к совместимости с предыдущими.
Ибо его разрабатывали не скриптовики, жабокодеры или растоманы.
Вот здесь убирают совместимость с Версией 3.5 (текущая 3.31) и делают версию 4.0.
Сообщая о поломке совместимости.
Почему не могут сделать совместимость в версией 1.0?
>Ибо его разрабатывали не скриптовики, жабокодерыА у этих что не так с "аккуратное отношение к совместимости с предыдущими." ?!?!?
Или ты это про JS?
Ты настолько молодой, что не помнишь python 2 ?
Сам ты вырвиглазный. Уж всяко лучше Makefile простыней в синтаксисе 70-х годов.
Ну конечно, хейтить всегда легче, чем понять и принять изменения. CMake может и не идеален, но он эволюционировал и стал неотъемлемой частью среды разработки C++. Вместо того чтобы тратить энергию на нытье, лучше было бы попробовать изучить и воспользоваться преимуществами, которые он предлагает. В конце концов, лидерство CMake в мире C++ говорит само за себя - возможно, стоит задуматься, почему это произошло, вместо того чтобы просто ругаться на него.
> стоит задуматься, почему это произошлоПотому же, почему и сам С++ получился таким же? :-)
Не - ну я серьёзно бы удивился если бы С++-ники сделали себе красиво :)))Не поймите меня правильно: cmake таки работает и с ним всё же лучше чем без него...
Да, история С++ действительно полна различных нюансов и компромиссов, но в конечном итоге он остается одним из самых мощных и широко используемых языков программирования. Точно так же, как и CMake, который, несмотря на свои недостатки, облегчает сборку проектов и делает жизнь разработчиков проще. Важно уметь видеть плюсы в том, что у нас есть, и стремиться к улучшениям, даже если это иногда требует некоторого терпения и труда. Похоже, что мы все в этом деле - постоянные искатели совершенства!
Какой-то странный ченджлог.Там намного больше изменений было, когда я в гит заходил.
>Прекращена совместимость с версиями CMake до выпуска 3.5соболезнования всем пользователям предыдущих версий
Ей уже больше 9 лет, ты о чём вообще?
Очевидно о том, что у некоторых проекты на системах где нет версий cmake старше 3.5.Но, я думаю. Там даже не версия 3, а скорее всего еще 2.
Так что тем кому надо и те системы поддерживать теперь будут два набора CMakeLists.txt писать.
> cmake старше 3.5младше же, конечно.
Скорее всего не будут, т.к. вполне можно без специфичных для cmake 3.5 вещей обойтись. Возможно для поддержки cmake 3.5 и cmake 4 одновременно придётся что-то переписать, но очень вряд ли прям потребуется иметь два разных CMakeLists.txt. Там нет каких-то эпичных несовместимостей. В крайнем случае может быть отдельный cmake-файлик с утилитами для 4 и 3.5, но и в таком случае какого-то значимого сопровождения это не потребует.В общем страх на пустом месте. На фоне остальных несовместимостей между такими системами вообще ни о чём.
Портабельные бинарные сборки для Linux и Windows (и не только) здесь: https://github.com/Kitware/CMake/releases/Либо то же самое, но упакованное в питонье колесо: https://pypi.org/project/cmake/
Если вы сами себя выбрали ограничивать своими же собственными правилами, то конечно пишите хоть два проекта, хоть сто двадцать два, главное чтобы счастливы были.
Вот только они для новых систем.На старых не запустяться.
Свежий cmake работает на rhel 6.
А что насчёт Alt?
У вас в продакшене используется старый Альт? А какой? Мастер 2.4?
> Свежий cmake работает на rhel 6.В смысле посылает нахрен с отсутствующими build deps? :D
Всё там есть, вплоть до gcc 11.Для boost я, правда, написал spec.
На самом деле не всё так просто. Для рабочих проектов конечно уже наплевать, а вот для обучающих материалов может стать проблемой, т.к. есть немало актуальной (несмотря на возраст) литературы, проекты которой собираются старыми CMake и тут у новичков в индустрии могут возникнуть проблемы на ровном месте. Хорошо конечно что старые версии легко доступны, но можно было бы просто создать слой совместимости чтобы старые проекты собирались, пусть даже выдаст предупреждение, что всё это давно устарело. C++ way - это про марафон, а не как проекты на Питоне, где у некоторых нейронок с кучей зависимостей срок годности меньше, чем у банки горошка.
В чём cmake 4 не совместим с cmake 3.5, из того, что может быть использовано в обучающих материалах? Там же не весь cmake поменяли, а дропнули поддержку старых политик совместимости, не более. Подавляющее большинство пользователей никаких проблем не найдёт, тем более в учебных материалах.
Напомню, что это тот самый CMake, в котором для того чтобы тебя поиметь достаточно добавить маленькую точку.
https://www.opennet.me/60888
> Напомню, что это тот самый CMake, в котором для того чтобы тебя поиметь достаточно добавить маленькую точку.
> https://www.opennet.me/60888Именно он!
Его писали люди воспитанные на баше и прочем доисторическом крапе.
Ну чтож поделаешь, ведь люди воспитанные на новомодном крапе - вообще ничего напрограммить не могут :)Других инженеров у меня для вас нет!(С)ВИС
вот тут ты вообще пальцем в небо. Точка сломает компиляцию проверочного кода независимо от системы сборки.
Не понимаю этих холиваров. Я в этих системах не разбираюсь совсем, говорю просто дикпику создай мне makefile с такими то м такими опциями и готово, всё работает как я хотел.
Держи нас в курсе, это всем интересно.
я не про то что интересно или неинтересно. а про то, что в отличии от программирования все эти чатгпт и дипсики умеют спми прекрасно и безошибочно сконфигурировать любую сборочную систему. Тратить на это свою жизнь смысла нет, лучше прокачиват скиллы в программировании.
я не про то что интересно или неинтересно. а про то, что в отличии от конфигурирования все эти чатгпт и дипсики умеют спми прекрасно и безошибочно программировать любую систему. Тратить на это свою жизнь смысла нет, лучше прокачиват скиллы в ????
> говорю просто дикпику создай мне makefile с такими то м такими опциями и готовоОпции указываются в симейклисте, не прочитав его опции не узнать, поэтому и указать что включить, а что нет — нельзя.
И что он тебе создаёт, скрипт на Bash?
По ходу вся суть в работе. У сишников весьма мало работы, вот они и сруться за технологии которые знают из-за денег в итоге получаемых на работе. То же касается и растовщиков - более молодой язык, более молодые люди в большинстве знает. А работать долго для богатой синьйорной специальности никто не хочет. А их технологии пересекаются в решении задач, вот и сруться друг с другом за технологии которые знают. Самое прикольное как они это лицемерно выставляют в итоге - всё вовсе не из-за денег, ну потому что прямо так никто написать или сказать нельзя - как бы не вежливо и за такую прямую позицию меньше заплатят или вообще не возьмут. Научились у пиндосов говорить одно, думать другое, да и по поступкам в общем-то показывать другое.
> Прекращена совместимость с версиями CMake до выпуска 3.5Ни дня без подвигов. Не прошло и полверсии.
Текущая была 3.31.Так что было 31-5 = 26 версий.
И о поломке совместимости они сообщили версией 4.0
Эталон для карго.
Make хватит практически для всего. Иногда вот попадаются проекты, не очень большие или совсем мелкие, бывает даже из кода там пара файлов, но зато сборочными скриптами там все знатно обмазано.
Зачем? Автор хотел похвастаться тем что шарит за сборочные системы? Ненужное переусложнение, очередное причем.
Много раз слышал мнение, что именно Make файлы писать сложно... Но зато имеем ситуацию когда чтобы собрать мелкий проект приходится тащить себе гору сборочного хлама, а если таких проектов несколько, то и хлама такого может быть много и разного, каждый же норовит выделиться и использовать разные билд системы...
Короче фигня это все, как в том анекдоте про стандарты.
>Make хватит практически для всегоАга, а потом по ошибкам компиляции угадывай, каких хидеров не хватает. Нет уж, кушайте сами.
> Make хватит практически для всего.Угу, особенно под винду и прочие плафтормы, которые не линакс. Сами кушайте свои баш-портянки.
Под Винду nmake.
под капотом у cmake куча внутренней кухни, и если захотел собрать чужой проект, в котором полагаются на внутренние определения, включая методы определения пакетов путем парсинга path, при этом cmake релизится с глюками ручного указания путей, то это прямая дорога в адд кроссозависимости внутренних переменных
GNU make и язык Си. Это всё что нужно для счастья.
Как там грамотно написать такое?# Функция всего лишь удаляет суффикс -unstable-v с цифрой из имени файла.
unvers = $(strip $(foreach v,1 2 3 4 5 6 7 8 9,\
$(if $(findstring -v$(v),$(1)),$(subst -unstable-v$(v),,$(1)),)))
wlproto = $(if $(findstring unstable,$(1)),unstable/$(call unvers,$(1)),stable/$(1))
Ещё один неосилятор ChatGPT)
Но у нового неосилятора и кода нет, а у меня есть. ;)
> Но у нового неосилятора и кода нет, а у меня есть. ;)Тот самый случай, когда код лучше удалить и не позориться.
>> Но у нового неосилятора и кода нет, а у меня есть. ;)
> Тот самый случай, когда код лучше удалить и не позориться.Тот самый случай, когда советчик нарушил своё же нравоучение, нажав кнопку "отправить" вместо "закрыть окно".
Код - это то, что собирается вон той писаниной. Но откуда программистам сборочных сценариев на диалекте баш это знать?
Хорошая система описания сборки, позволяет делать типичные вещи интуитивно просто. Но всегда находятся неучи, неосилившие документацию.
> Хорошая система описания сборки,Настолько хорошая, что есть такое понятие как modern cmake?
>> Хорошая система описания сборки
> Настолько хорошая, что есть такое понятие как modern cmake?Именно. Разработчики учитывают ошибки и делают систему лучше.
для простых проектов годится. для сложных набор адских костылей. например, где каждый пакет имеет свои установки для минимальной версии cmake или cmake не поддерживает компилятор или приходится использовать костыли из cmake и json (несколько компиляторов llvm, msvc, icx, но унылый cmake очень умный и живёт своей жизнью, игнорируя прямые указания по выбору компилятора, тут уже не обойтись без допкостылей на json).
> для простых проектов годится. для сложных набор адских костылей. например, где каждый
> пакет имеет свои установки для минимальной версии cmake или cmake не
> поддерживает компилятор или приходится использовать костыли из cmake и json (несколько
> компиляторов llvm, msvc, icx, но унылый cmake очень умный и живёт
> своей жизнью, игнорируя прямые указания по выбору компилятора, тут уже не
> обойтись без допкостылей на json).Тут есть два путя: прочесть документацию или не использовать CMake. Вас кто-то под дулом пистолета заставляет использовать CMake?
Третий путь: использовать CMake, но вместо слова "хороший" использовать "наименее плохой". CMake предсказуемо страдает от того, что системы сборки разрабатываются по остаточному принципу и изобретают свои недо-DSL.Новичок сумеет написать такое и как ему чтение документации[1] поможет? Никак.
set(SOMELONGVARIABLENAME "X")
set(ANOTHERLONGVARIABLENAME "X")if (SOMELONGVARIABLENAME STREQUAL ANOTHERLONGVARIALENAME)
message("Hello World")
endif()
~~~~~~~~~~
cmake --warn-uninitialized -P example.cmake[1] https://cmake.org/cmake/help/latest/manual/cmake.1.html#cmdo...
(не говоря уж о другим недостатках этой функции: https://gitlab.kitware.com/cmake/cmake/-/issues/24409)
>[оверквотинг удален]
> Новичок сумеет написать такое и как ему чтение документации[1] поможет? Никак.
>set(SOMELONGVARIABLENAME "X")
> set(ANOTHERLONGVARIABLENAME "X")
> if (SOMELONGVARIABLENAME STREQUAL ANOTHERLONGVARIALENAME)
> message("Hello World")
> endif()
> ~~~~~~~~~~
> cmake --warn-uninitialized -P example.cmake
> [1] https://cmake.org/cmake/help/latest/manual/cmake.1.html#cmdo...
> (не говоря уж о другим недостатках этой функции: https://gitlab.kitware.com/cmake/cmake/-/issues/24409)Чтение документации поможет осознать, что подобные опечатки не трактуются как ошибки и уж если нужно делать хитрую логику, то ее нужно тестировать. Другой вопрос, зачем новичку поручают делать какие-то сложные штуки с системой сборки.
> Чтение документации поможет осознать, что подобные опечатки не трактуются как ошибки и
> уж если нужно делать хитрую логику, то ее нужно тестировать.То есть... ты сам не осилил CMake?
> подобные опечатки не трактуются как ошибкиОни должны трактоваться как предупреждения, использовал опцию --warn-uninitialized и рассчитываю получить dev warning. Но не получу.
Не получу, потому что --warn-uninitialized работает только при разыменовании переменных (документация?..), но в данном случае с ним тоже не сработает (документация?..).
Могу дописать -Werror=dev, чтобы превратить соответствующий dev warning в ошибку. Но он не превратится из-за бага аналогичного этому: [1] (документация?..).
> Другой вопрос, зачем новичку поручают делать какие-то сложные штуки с системой сборки.
И кому их поручать, если ты сам не знаешь про эти проблемы и их незадокументированность?
> но в данном случае с ним тоже не сработает (документация?..).(невнимательность!..)
Но вместо этого можно добавить, что -Wno-dev не для всех dev warning работает.
И неявные разыменования в if'ах позволяют выстрелить в ногу интереснее, чем в шеллах или сишном препроцессоре, [s]новым мейнтейнерам xz может пригодиться[/s]:
https://stackoverflow.com/questions/49605059/numeric-only-va...
> --warn-uninitialized работает только при разыменовании переменныхПри *явном* разыменовании переменных, то бишь.
> И неявные разыменования в if'ах позволяют выстрелить в ногу интереснее, чем в шеллах или сишном препроцессоре
Хм, идея оператора if без неявного разыменования была, обсуждали 11 лет назад и на этом заглохло.
https://cmake.org/pipermail/cmake-developers/2014-September/...
> То есть... ты сам не осилил CMake?Хорошо, я не осилил CMake, мои сценарии сборки на нем просто работают.
>> подобные опечатки не трактуются как ошибки
> Они должны трактоваться как предупреждения, использовал опцию --warn-uninitialized и
> рассчитываю получить dev warning. Но не получу.Ещё раз – сложную логику выноси в модули и тестируй отдельно. Работай, а не ной. Или увольняйся с работы, где заставляют использовать CMake.
Откуда такое желание раздавать советы "прочесть документацию", не читая её самому?> Ещё раз – сложную логику выноси в модули и тестируй отдельно. Работай,
> а не ной. Или увольняйся с работы, где заставляют использовать CMake.Ноешь здесь ты, "я документацию не читал, но там наверняка написано...", "не обижайте мой симейк", "пишите тесты" (и подключайте дебаггеры к json'у, ага).
Я сразу написал:
> Третий путь: использовать CMake, но вместо слова "хороший" использовать "наименее плохой"
.
Да кошмарная на самом деле (как, впрочем, вообще весь тулинг в C/C++ мире), просто другие ещё хуже, на этом и выезжает.
> Да кошмарная на самом деле (как, впрочем, вообще весь тулинг в C/C++
> мире), просто другие ещё хуже, на этом и выезжает.А где хорошо? Гвоздями прибитые монстры для новых язычков? А вот С, С++ (и не только) можно при желании обычным make собрать.
>А где хорошо?В голанге хороший тулинг, в хашкеле (cabal) тоже ничего.
>А вот С, С++ (и не только) можно при желании обычным make собрать
Эм... и что? Фанфэктами делишься просто?
>>А где хорошо?
> В голанге хороший тулинг, в хашкеле (cabal) тоже ничего.Чем хорош? Что завязан на одну контору?
>>А вот С, С++ (и не только) можно при желании обычным make собрать
> Эм... и что?А то, что можно при желании обойтись без всякой мутной хрени достаточно просто. Напомни, сколько кода в cargo или dune окамлевском?
При желании можно код в блокнот через микрофон насвистывать, и чего? Исходники голангового тулинга открыты, как и сам язык, какая одна контора? При чём тут объём кода в cargo? Ты по методичке что ли шпаришь? :)
> При желании можно код в блокнот через микрофон насвистывать, и чего?Понасвистывай.
> При чём тут объём кода в cargo?
Притом, что рано или поздно тебе придется туда залезть. Инструменты должны быть простыми, легко собираться, легко читаться и обладать гибкостью. А не быть узкоспециализированными монстрами.
>Инструменты должны быть простыми, легко собираться, легко читаться и обладать гибкостью. А не быть узкоспециализированными монстрами.Жёстко ты про CMake.
> Исходники голангового тулинга открыты, как и сам язык, какая одна контора?А ты смешной. Если контора не одна, то кому телеметрия в компиляторе стучит?
Телеметрия стучит занимающейся разработкой этого тулинга конторе, но отсылку надо явно включать. Ну и опять же при чём тут телеметрия? Как телеметрия «завязывает всё на одну контору», если код открыт? Реально по методичке шарашишь.
> Телеметрия стучит занимающейся разработкой этого тулинга конторе, но отсылку надо явно включать.Вроде, по дефолту уже врубали? Хотя так то окно Овертона штука такая...