Представлен релиз кроссплатформенного открытого генератора сценариев сборки CMake 3.22, выступающего в качестве альтернативы Autotools и используемого в таких проектах, как KDE, LLVM/Clang, MySQL, MariaDB, ReactOS и Blender. Код CMake написан на языке C++ и распространяется под лицензией BSD...Подробнее: https://www.opennet.me/opennews/art.shtml?num=56205
лучшая тулза для билда
не лучше так
лучшая() тулза() для() билда()
это вам не мехон
и не репка ...
Все хочу попробовать скрестить язык tcl и cmake и посмотреть, как изменится красивость скриптов моих, да все времени нет..
для красивости к cmake добавляют rust со вставками на perl, в которых внутри вставки на haskell
И всё это облепят Electron'ом.
простите вы там не удр-ись?
>И всё это облепят Electron'ом.через electron-jvm
Это все фингня, завезли ли в него поддержку новой студии? Уже можно студию обновлять или еще ждать?
Да уже завезли, было ещё в одном из предыдущих выпусков. Плюс сама студия идёт с CMake'ом с такой поддержкой.
В одном из Preview выпусков студии шла версия CMake без поддержки 2022 студии, но там основной сценарий сборка через Ninja так что генерация солюшена и проектов 2022 не критично, с точки зрения MS.
Студия не нужна
Тоже ставите только Windows SDK ?
вопрос только в том как автоматом научить clang понимать где он что бы не прописывать какие-то непонятные номера в скриптах
> Тоже ставите только Windows SDK ?
> вопрос только в том как автоматом научить clang понимать где он что
> бы не прописывать какие-то непонятные номера в скриптахНет, в моем мировозрении операционные системы windows и osx и софт для них отсутствует.
> вопрос только в том как автоматом научить clang понимать где онТо ли это вопрос "как прописать PATH", то ли "виндапроблемы".
Первое решается просто по первой же ссылке в гугле https://losst.ru/peremennaya-path-v-linux, второе решается не просто, а очень просто "виндузятники мазахисты, не нужно лишать их удовольствия от страданий"
На всякий случай отмечу что кривое поделие под названием WSL относится к "виндапроблемам". WSL это не линух, WSL это кусок !@#$%^.
Кусок Убунты вы хотели сказать?
Сколько перепробовал систем сборки и понял что только premake все делает правильно.
Когда в premake можно будет скомпилировать хедер и посмотреть какие дефайны были выставлены?
По идее никто не запрещает написать например make help, чтобы увидеть сгенерированные цели, а затем если вам хочется - вы можете натравить make на эту цель в режиме холостой печати иииии вывод грепнуть целом не смотря на всё сказанное все дефайны компилятору вполне поддаются обнаружению. Как альтернативу вы можете добавить возможностей в примейк-рецепт и настроить его выводить что душе угодно.
надо взглянуть, а то он еще и на сях и даже с нормальными ключевыми словами, а если еще и умеет библиотеки сам искать через pkg-config то вообще цены ему нет
Так ведь там нет ничего, что выходит за пределы возможностей gnu make + friends.
> минимальным числом зависимостейЛПП
> нет привязки Perl или Python
Которые все равно есть в любом дистрибутиве (где собирают ПО из исходников, то есть не embeded)
Зато есть зависимости от libuv libjson-cpp libarchive curl librhash и nghttp2 (последний то зачем??? )
Наличие их копий в тарболе ни чего не меняет. Без учета того что есть везде их как минимум 6. У ninja/meson и scons - только python который везде, у autotools - perl (тож везде) и m4
> (последний то зачем??? )как минимум просто потому что libcurl притащил
>> нет привязки Perl или Python
> Которые все равно есть в любом дистрибутивемир для которого предназначен cmake пока еще не исчерпывается вашими одинаковыми клонами systemd/linoops отличающимися только нескучными обоями.
К тому же возникают разночтения, к какой наираспоследней версии впихона вам удалось необратимо привязать ваш любимый сборочный ненужно-инструмент.
Зависимость от libuv (которая со всем миллиардом собственных зависимостей не собирается нормально без самого cmake) конечно не подарок, но по другому они уже все равно давно разучились.
Если что - autotools не предназначены для запуска на целевой системе вообще. configure требует наличия только posix shell.
>>> нет привязки Perl или Python
>> Которые все равно есть в любом дистрибутиве
> мир для которого предназначен cmake пока еще не исчерпывается вашими одинаковыми клонами
> systemd/linoops отличающимися только нескучными обоями.в дистрибутивах bsd нет пихона? systemd тут каким боком?
> ваш любимый сборочный ненужно-инструмент.
Мой любимый сборочный инструмент (autotools) к пихону не привязан
> Зависимость от libuv (которая со всем миллиардом собственных зависимостей не собирается
> нормально без самого cmake)Ну вообще то libuv только от libc зависит и использует autotools
> Если что - autotools не предназначены для запуска на целевой системе
> вообще. configure требует наличия только posix shell.Знаю. Я про то что "минимальное число зависимостей" у cmake не выходит ну никаким боком, не важно с чем сравнивать
в операционной системе freebsd нет не только пихона (какой из последних несовместимых версий?), но двадцать лет как нет уже и перла. Кстати, обратите внимание - сама она собирается без всего этого хлама. (и конфигурируется, угу)
Разумеется, кому очень надо, может все это пока поставить из портов (пока, потому что циклические зависимости скоро некому будет разруливать).Да, про libuv это склероз подвел - с ней все в порядке, а вот jsoncpp требует мезон, самую наираспоследнюю версию впихона и девственниц в жертву.
> в операционной системе freebsd нет не только пихона (какой из последних несовместимых
> версий?), но двадцать лет как нет уже и перла. Кстати, обратите
> внимание - сама она собирается без всего этого хлама. (и конфигурируется,
> угу)Ок, я bsd не пользовался, а т.к. python/perl просит половина пакетов из LFS (базовой системы) (про BLFS и остальное вообще не говорю) жизнь без них не представлял возможной
> Разумеется, кому очень надо, может все это пока поставить из портов (пока,
> потому что циклические зависимости скоро некому будет разруливать).Да, с циклическими (и вообще с любыми) зависимостями становится все хуже... Но в принципе у питона большинство зависимостей опциональны, а perl их мало и врятли будет сильно расти. Но зависимости зависимостей тоже могут "расти"
> какой из последних несовместимых версий?
Python2 EOL, но пока требуется некоторым софтом (android для сборки например хочет). Думаю что скоро умрет окончательно.
> Python2 EOL, но пока требуется некоторым софтом (android для сборки например хочет). Думаю что скоро умрет окончательно.Вас бы google со своим android'ом послушал...
да ну, бросьте, не умрет андроид. фикция - это фикция. мертворожденное ненужно. Гугль рожает такие прожекты пачками, и так же пачками они мрут. А работающие продолжаются вечно.так и будете собирать для него в уголке свой особый пихон2 десятилетней выдержки. фигли делать-то...
ээээ.... возможно. Я, правда, на 1/2 android'ную сборку увёл под третий питон (до той степени, до которой мне нужно было). Но то --- я.
Уважаемый, а ты что, чтобы поставить cmake, собираешь его из исходников с зависимостями? Открой для себя репозитории, там все есть и все скомпилировано до тебя. Чтобы использовать собирать cmake-проект, не нужно при этом сам cmake бутстрапить. Не страдай фигней.
> Уважаемый, а ты что, чтобы поставить cmake, собираешь его из исходников с зависимостями?да. Причем не со всем интернетом, сволочь такая, а только с той частью, которую совсем уж никак не оторвать.
> Открой для себя репозитории
спасибо, а зачем мне тогда cmake был бы нужен? То что им собирается, наверняка уже кем-то собрано и рядом выложено.
К счастью, мир пока еще не кончается на единственном вашем systemd/linoops, непременно последней версии (предпоследнее ведро несовместимо с данной версией Systemd)
Ну ты и отбитый. Удачи тебе с твоей нелинукспомойкой. Если что, приходи годика через два, когда уму-разуму наберешься и фанатизм подрастеряешь, научим тебя как на промышленных средах проекты собирать и не конпелять при этом половину сборочной системы.
Кошмарная система сборки. К сожалению у нее нету альтернатив - пользуюсь и плачу, плачу и пользуюсь.
мы только что обнаружили что без meson ты ее зависимости зависимостей даже и не соберешь.Ну так а зачем тебе еще одна такая же?
нужно подождать когда они сдадутся и свой CMake будут собирать через meson
уже могли бы постепенно идти друг другу на встречу ключевые слова подбирать
синтаксис улучшать, но нет стоят на своем
> Ну так а зачем тебе еще одна такая же?Мне не нужна такая же. Мне нужна нормальная.
Ну сам же признаешь что это что угодно но не cmake - так зачем же ж страдать?
Потому что у заказчиков большой проект именно на симейке, а малой кровью перевести эту кучу малопонятных портянок на что-то другое не получится. Ну а за большую кровь оне платить не согласны.
> Ну сам же признаешь что это что угодно но не cmake -
> так зачем же ж страдать?Пох, скажи пожалуйста, а какая система сборки хорошая (ну, или зная твое отношение к современной разработки ПО, наименее говенная)? Окромя самописных posix Makefile'ов, разумеется.
А почему нет, кстати? Хотя bmake поинтереснее будет. Кстати, она вполне портируема, собирается autoconf, и, разумеется, ее писали в те древние прекрасные дни когда никому в голову не приходило намеренно удалять configure из релиза - поэтому для просто сборки на поддерживаемой платформе autotools тоже не требуются - достаточно posix shell.А если тебе в портируемый софт - то замены autoconf мне неизвестны. Потому что его магия реально решает некоторые проблемы, которые в остальных случаях либо не требуют решения (бесконечные поиски того что во всех системах лежит в одном и том же месте, причем всегда) либо решаются только вручную.
> Кошмарная система сборки.А что с ней не так? Я ей пользовался только как пользователь, и в таком формате она вполне работает.
Худшая система сборки.Начиная от упоротого синтаксиса и отсутствия толковой документации, заканчивая просто нерабочими модулями.
подтверждаю. сталкивался в паре проектов.
нахлебался щей. в целом пока или классика Make/autotols или meson (хотя тут сложно) они там тоже какие-то обкуренные
> нахлебался щей.Пока остаешься под никсами мейк непревзойден и велоколепен. В связке с башем и авк - комбайн, и код сбилдить, и тесты прогнать, и почистить, и документацию нагенерить.
Но, к сожалению, приходится собирать и под студию. И если под офтопик, в принципе, можно mingw через мейк попользовать (и тесты через wine прогнать), то студией собрать никак.
Посему без симейка никуда. Печаль. Вот прямо сейчас страдаю, запуская через ремут десктоп "cmake --build . --target BUILD_ALL INSTALL". Блин, даже командная строка через _опу...
И что мешает и там использовать make? Или нужна именно сама студия, с интуитивно-понятными кнопочками "скачать с гитхапа или гитляпа и собрать"?
Да, нужна именно студия. С ее идиотскими кнопочками "собрать", "запустить", "ждать полчаса пока дебаггер поймет что надо брекпоинт поставить".
пох, вы таки будете смеяться, но во времена, когда мне нужно было собирать и под W., я так и делал. С cygwin'ом получалось менее затратно, чем впрямую с nmake'ом. Студия --- неприемлемо (там под ней nmake и остался?). Оно упорно хотело только абсолютные пути и более одного варианта сборки на одной машине уживались с заметными усилиями.Но давно это было. Судя по запросам/комментариям --- всё осталось так же.
&"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\nmake"Microsoft (R) Program Maintenance Utility Version 14.00.24245.0
Copyright (C) Microsoft Corporation. All rights reserved.NMAKE : fatal error U1064: MAKEFILE not found and no target specified
Stop.Ничего не поменялось. Ну а для путей (которые вполне могут быть относительными ;-) как раз предназначены скрипты конфигурации.
Но, увы, студия любит cmake, отлично с ним интегрировалась и хочется убивать, убивать, убивать...
> Пока остаешься под веществами мейк непревзойден и велоколепен.исправил, не благодари
make и autotools на несколько порядков хуже CMake. Последний по крайней мере умеет генерировать правила для ninja
> Последний по крайней мере умеет генерировать правила для ninjaЭто которого потом может запустить meson ? Да , отличная штука.
кто то пользуется этим отстоем?
Никто, эта шляпа была до месона. Но объективно она способна выкачать исходники зависимости из сф и собрать их использовав автомейк и всё остальное -- это мой кейс 10 летней давности, что ещё просить? Кроссплатформенно, популярнее pkg-config. С тех пор я либо поставляю ворованную копию исходников (как это делают большинство проектов), либо заставляю пользователей самостоятельно разбираться с зависимостями. Это очень упрощают сопровождение.