CMake тут не в чем винить — у вас очень странная хотелка и я не знаю систем сборки которые позволяли бы для каждой зависимости индивидуально контролировать где её искать. Обычно разные окружения ставят целиком в разные префиксы и указывают CMAKE_FIND_ROOT_PATH, больше ничего не надо.
Был бы он так приятен и понятен, не пилилось бы ему тогда 100 альтернатив и не писались бы статьи на хабре о том, как его заменить.
Альтернатива ему пилится ровно одна — meson. От второй, qbs, сами авторы отказались в сторону CMake — не был бы он так приятен и понятен, этого бы не произошло. Но я не настаиваю — используйте любую другую высокоуровневую систему сборки. Посыл был прежде всего в том чтобы не писать скрипты вручную.
А какая разница как описать структуру проекта? Декларативно или в виде набора команд с флагами разными? Грубо говоря, количество информации которое вам, как разработчику, нужно ввести в компьютер, чтобы объяснить ему правила для сборки — и в том и в другом случае одинаковое
Ну конечно же нет, в том то и дело. Количество информации различается на порядки. Команды и флаги будут разными на разных системах, компиляторах, дистрибутивах и версиях одного дистрибутива. Например, чтобы подключить потоки может потребоваться -pthread, -lpthread, -lthr только на BSD. -ldl на FreeBSD не существует, а на Linux нужен. C++17 может включаться как -std=c++17, -std=c++1z, /std:c++17, где-то вообще быть по умолчанию. Банальная сборка статической библиотеки это два ни разу не очевидных вызова ar/runlib только на *nix, в windows вообще по другому. У install есть несовместимости в аргументах между GNU и BSD версиями. Как и у sed, awk, grep и что вы там ещё будете звать из ваших скриптов.
В CMake каждая из этих операций делается ровно одной строкой, которая описывает сама себя и работает везде, даже на solaris и haiku, даже если вы о них первый раз слышите.
Подход интересный, но в современном мире у make осталась слишком узкая ниша чтобы переживать из-за его проблем.
Если мы про сборку ПО, то уж извините, но никто кроме горстки радикалов которым не угодил размер CMake (на самом деле сборка — это сложно, и эта сложность так или иначе должна где-то обитать; очень недальновидно отказываться от замечательного инструмента который всю это сложность инкапсулирует и поддерживает за вас, тащить её себе в проект и потом нести бремя поддержки) не пишет руками россыпь императивных скриптов (и в особенности не парсит include sed'ом), когда можно декларативно написать "нужна библиотека A из исходников X и исполняемый файл B из исходников Y и этой библиотеки" на CMake, и из него получить сборку хоть на make, хоть на ninja, хоть на msbuild, хоть на том же redo (если кто-то напишет генератор) или проекты под любые IDE, и это будет нормально обрабатывать зависимости, работать с любыми компиляторами, уметь кросс-компиляцию, выполнять все требования к сборке (а не только те что вы не забыли) и ещё много много всего что вам придётся либо писать руками, либо вы написать забудете (сломав кому-то сборку), либо просто не сможете не продублировав весь набор скриптов и/или не превратив его в include лапшу. И это будет не требуя от вас вообще никаких затрат развиваться и поддерживать новые возможности существующего инструментария и новые инструменты.
Так что, вашими же словами, CMake настолько впечатлил life-changing простотой, гибкостью и куда лучшим выполнением задач сборки, что я во всех своих проектах им полностью заменил make (вместе с qmake, scons, autotools) и точно не поменяю на redo.
Помимо сборки софта, в простых случаях я однозначно предпочту make, только за то что его все знают (POLA) и за наглядность (один файл, удобное задание переменных для подстановки (=, ?=, += без лишних скобок и кавычек), далее все цели в одном месте). Для простых, повторюсь, случаев есть небольшое общее подмножество GNU/BSD синтаксисов с которым make по прежнему везде есть, и перечисленные вами минусы неактуальны, так что остаются только плюсы.
А вот прям сложные случаи сборки не-софта, с разветвлённым деревом зависимостей и разнообразными процессами, требующими вызова внешних утилит — тут да, можно и рассмотреть redo.
почему Git, работающий временами с довольно таки неочевидной логикой, настолько популярнее гораздо более логичного Mercurial
Может потому что как раз с логикой там всё в порядке, а если вы к чему-то привыкли не значит что это единственный и тем более единственно верный вариант того как может быть?
Мой опыт работы с mercurial начался с непозволительно медленной для VCS последнего поколения работы с большим репозиторием, сильного удивления от закрытых веток и в итоге попадания в multihead состояние, которое я с ходу не разобрался как разрешить, на том и закончился. Просто как пример того что оценка очевидности субъективна.
откатываешь коммиты, не думая о том, что находится под капотом системы контроля версий, и об указателе на Head, а просто делая то, что нужно?
Так работают с любой VCS, когда не требуют от неё быть другой VCS.
один из столпов сопротивления мейнстриму в системах контроля версий
О как. А какой смысл в этом сопротивлении? Последствий кроме усложнения взаимодействия разработчиков я не вижу.
Перипетии не несут никакой самостоятельной ценности. Ценность несёт целостная, последовательная история состоящая из небольших атомарных коммитов с описательными комментариями, а таковую почти никогда не получить если просто периодически фиксировать состояние процесса разработки, поэтому редактирование истории — насущная необходимость и хороший тон. Но только до вливания в основную ветку, естественно.
Лично мне не нравится то, что поклонники Git любят использовать возможность править историю коммитов.
Это не прерогатива поклонников Git, поклонники mercurial всегда хвалились MQ, Evolve и подобными расширениями.
Я вполне допускаю мысль, что на самом деле просто этическая норма устарела, такое в истории человеческого общества бывало не раз и не два.
Можно также допустить и другую мысль, о том что устарело представление о обязательности/необходимости оплаты (в классическом понимании, деньгами) за определённые виды контента. Примеров этому тоже достаточно, например СПО, Википедия и OSM.
Лишняя возня со сборкой, а премуществ никаких особо и нет.
Возня со сборкой получается когда пакеты собираются вне системного репозитория, и зачастую не могут найти нужные нативные библиотеки и компилятор. А потом получается ещё больше возни, потому что системные библиотеки обновляются или удаляются, не зная ничего о том что от них зависят питоновские модули, в итоге ломая последние. Нет, система управления пакетами должна быть единой для всего.
или в pypi, или в нативный пакет для операционной системы
Я ни разу не встречал проблем с опакечиванием питоновых приложений хоть с PyPI, хоть напрямую с GitHub — setup.py делает всё что нужно и создаёт исполняемые файлы в bin — это работает и c __main.py__, и со скриптами.
Проблема, повторюсь, возникает при работе с репозиторием, потому что с __main__.py скриптов в нём не будет и чтобы пользоваться приложением из чекаута репозитория вам придётся, по сути, сначала руками распарсить entry_points из setup.py, или искать __main__.py.
Считаю что оформлять приложения в виде модулей это плохая идея, вместо этого использую *.py в корне проекта для приложений и подкаталоги для библиотек. Так сразу видно что можно запускать напрямую без поиска __main__.py, не нужно никаких python -m для запуска, не создаётся искусственных связей между приложениями и библиотеками, которые потом мешают расширять проект (т.е. добавлять новые приложения, разбивать и объединять библиотеки, разбивать весь репозиторий). Примерная структура одного из текущих проектов:
├── mycoolservice-updater.py # backend демон обновляющий данные
├── mycoolservice-*.py # какие-то ещё вспомогательные backend утилиты
├── mycoolservice-webapp.py # веб-приложение
├── mycoolservice # основная логика, используется всеми
│ ├── __init__.py
│ └── *.py
└── mycoolserviceweb # логика специфичная для веб приложения, вьюхи
├── __init__.py
└── *.py
А __main__.py я бы оставил только для особой функциональности модулей типа python -m json.tool
Тебе не отпустят товары, если заподозрят, что нескоро получат от тебя оплату. Чем выше отрицательный остаток на лицевом счете, тем дольше ожидать возмещения за товар.
Какой ещё оплаты? Оплата — это долговая расписка которую я даю сразу.
Док: Почему патовая? Ты можешь передать свой товар в кредит, за что получить расписку. Эту расписку договоримся считать деньгами.
Не вижу почему первая расписка которую я дал будет чем-то хуже миллион первой.
Не понял какой механизм мешает жить в этой системе в бесконечный долг. Рост оного, кстати, и будет суть обогащением.
Антиэкономика предполагает переторговывание и произвольное использование денег, тем самым развивает в человеке его худшие качества
Не знаю насколько это риторика о качествах человека уместна в научной, как вы выражаетесь, теории. А так-то, только из этого
поскольку дети с рождения обладают собственными суммами на своих лицевых счетах
следует много чего нехорошего, вплоть до противоречия исходному постулату "каждому по труду", ибо дети производителя эффективного орудия могут не работать вообще, а дети должника (если таки механизм ограничения долга существует) не выживут не работая с пелёнок.
Попали уже несколько лет назад (ALT, AUR, FreeBSD, nix, Rosa)
CMake тут не в чем винить — у вас очень странная хотелка и я не знаю систем сборки которые позволяли бы для каждой зависимости индивидуально контролировать где её искать. Обычно разные окружения ставят целиком в разные префиксы и указывают CMAKE_FIND_ROOT_PATH, больше ничего не надо.
Альтернатива ему пилится ровно одна — meson. От второй, qbs, сами авторы отказались в сторону CMake — не был бы он так приятен и понятен, этого бы не произошло. Но я не настаиваю — используйте любую другую высокоуровневую систему сборки. Посыл был прежде всего в том чтобы не писать скрипты вручную.
Ну конечно же нет, в том то и дело. Количество информации различается на порядки. Команды и флаги будут разными на разных системах, компиляторах, дистрибутивах и версиях одного дистрибутива. Например, чтобы подключить потоки может потребоваться
-pthread,-lpthread,-lthrтолько на BSD.-ldlна FreeBSD не существует, а на Linux нужен. C++17 может включаться как-std=c++17,-std=c++1z,/std:c++17, где-то вообще быть по умолчанию. Банальная сборка статической библиотеки это два ни разу не очевидных вызова ar/runlib только на *nix, в windows вообще по другому. У install есть несовместимости в аргументах между GNU и BSD версиями. Как и у sed, awk, grep и что вы там ещё будете звать из ваших скриптов.В CMake каждая из этих операций делается ровно одной строкой, которая описывает сама себя и работает везде, даже на solaris и haiku, даже если вы о них первый раз слышите.
Подход интересный, но в современном мире у make осталась слишком узкая ниша чтобы переживать из-за его проблем.
Если мы про сборку ПО, то уж извините, но никто кроме горстки радикалов которым не угодил размер CMake (на самом деле сборка — это сложно, и эта сложность так или иначе должна где-то обитать; очень недальновидно отказываться от замечательного инструмента который всю это сложность инкапсулирует и поддерживает за вас, тащить её себе в проект и потом нести бремя поддержки) не пишет руками россыпь императивных скриптов (и в особенности не парсит include sed'ом), когда можно декларативно написать "нужна библиотека A из исходников X и исполняемый файл B из исходников Y и этой библиотеки" на CMake, и из него получить сборку хоть на make, хоть на ninja, хоть на msbuild, хоть на том же redo (если кто-то напишет генератор) или проекты под любые IDE, и это будет нормально обрабатывать зависимости, работать с любыми компиляторами, уметь кросс-компиляцию, выполнять все требования к сборке (а не только те что вы не забыли) и ещё много много всего что вам придётся либо писать руками, либо вы написать забудете (сломав кому-то сборку), либо просто не сможете не продублировав весь набор скриптов и/или не превратив его в include лапшу. И это будет не требуя от вас вообще никаких затрат развиваться и поддерживать новые возможности существующего инструментария и новые инструменты.
Так что, вашими же словами, CMake настолько впечатлил life-changing простотой, гибкостью и куда лучшим выполнением задач сборки, что я во всех своих проектах им полностью заменил make (вместе с qmake, scons, autotools) и точно не поменяю на redo.
Помимо сборки софта, в простых случаях я однозначно предпочту make, только за то что его все знают (POLA) и за наглядность (один файл, удобное задание переменных для подстановки (
=,?=,+=без лишних скобок и кавычек), далее все цели в одном месте). Для простых, повторюсь, случаев есть небольшое общее подмножество GNU/BSD синтаксисов с которым make по прежнему везде есть, и перечисленные вами минусы неактуальны, так что остаются только плюсы.Вот примеры таких Makefile для наглядности:
https://github.com/repology/repology-logo/blob/master/Makefile
https://github.com/repology/repology-linkchecker/blob/master/Makefile
А вот прям сложные случаи сборки не-софта, с разветвлённым деревом зависимостей и разнообразными процессами, требующими вызова внешних утилит — тут да, можно и рассмотреть redo.
Может потому что как раз с логикой там всё в порядке, а если вы к чему-то привыкли не значит что это единственный и тем более единственно верный вариант того как может быть?
Мой опыт работы с mercurial начался с непозволительно медленной для VCS последнего поколения работы с большим репозиторием, сильного удивления от закрытых веток и в итоге попадания в multihead состояние, которое я с ходу не разобрался как разрешить, на том и закончился. Просто как пример того что оценка очевидности субъективна.
Так работают с любой VCS, когда не требуют от неё быть другой VCS.
О как. А какой смысл в этом сопротивлении? Последствий кроме усложнения взаимодействия разработчиков я не вижу.
Перипетии не несут никакой самостоятельной ценности. Ценность несёт целостная, последовательная история состоящая из небольших атомарных коммитов с описательными комментариями, а таковую почти никогда не получить если просто периодически фиксировать состояние процесса разработки, поэтому редактирование истории — насущная необходимость и хороший тон. Но только до вливания в основную ветку, естественно.
Это не прерогатива поклонников Git, поклонники mercurial всегда хвалились MQ, Evolve и подобными расширениями.
Упустили как минимум generator expressions и обычные генераторы (с yield).
Можно также допустить и другую мысль, о том что устарело представление о обязательности/необходимости оплаты (в классическом понимании, деньгами) за определённые виды контента. Примеров этому тоже достаточно, например СПО, Википедия и OSM.
"Нормальных" не существует.
У вас собирательный образ обычного разработчика с талантом и эрудицией выше среднего. Собрались лечить всех разработчиков или сам образ?
Я это и сам выше процитировал. На вопрос вы не ответили.
Не будь смысла, опакечивание Python модулей не было бы распространено повсеместно: https://repology.org/projects/?search=python%3A
Возня со сборкой получается когда пакеты собираются вне системного репозитория, и зачастую не могут найти нужные нативные библиотеки и компилятор. А потом получается ещё больше возни, потому что системные библиотеки обновляются или удаляются, не зная ничего о том что от них зависят питоновские модули, в итоге ломая последние. Нет, система управления пакетами должна быть единой для всего.
Я ни разу не встречал проблем с опакечиванием питоновых приложений хоть с PyPI, хоть напрямую с GitHub —
setup.pyделает всё что нужно и создаёт исполняемые файлы вbin— это работает и c__main.py__, и со скриптами.Проблема, повторюсь, возникает при работе с репозиторием, потому что с
__main__.pyскриптов в нём не будет и чтобы пользоваться приложением из чекаута репозитория вам придётся, по сути, сначала руками распарситьentry_pointsизsetup.py, или искать__main__.py.Скрипт можно запускать точно так же, причём на 1 аргумент короче.
Никакого геморроя. Много кто так и делает, см., например, ansible и black.
Возмещения в чём помимо долговых бумажек он ожидает?
Я всё ещё не вижу что мне помешает жить в бесконечный долг, добросовестно потребляя купленные в долг товары (что выгодно производителю).
Считаю что оформлять приложения в виде модулей это плохая идея, вместо этого использую
*.pyв корне проекта для приложений и подкаталоги для библиотек. Так сразу видно что можно запускать напрямую без поиска__main__.py, не нужно никакихpython -mдля запуска, не создаётся искусственных связей между приложениями и библиотеками, которые потом мешают расширять проект (т.е. добавлять новые приложения, разбивать и объединять библиотеки, разбивать весь репозиторий). Примерная структура одного из текущих проектов:А
__main__.pyя бы оставил только для особой функциональности модулей типаpython -m json.toolКакой ещё оплаты? Оплата — это долговая расписка которую я даю сразу.
Не вижу почему первая расписка которую я дал будет чем-то хуже миллион первой.
Не понял какой механизм мешает жить в этой системе в бесконечный долг. Рост оного, кстати, и будет суть обогащением.
Не знаю насколько это риторика о качествах человека уместна в научной, как вы выражаетесь, теории. А так-то, только из этого
следует много чего нехорошего, вплоть до противоречия исходному постулату "каждому по труду", ибо дети производителя эффективного орудия могут не работать вообще, а дети должника (если таки механизм ограничения долга существует) не выживут не работая с пелёнок.