Это не имеет значения потому что есть catch(...), а вообще код который кидает что-то не унаследованное от std::exception можно смело приравнивать к ill-formed.
Помню sonique, про него ещё ходили слухи что в нем качество звучания лучше из-за собственного декодера. Но ни winamp ни sonique удобными с точки зрения gui никогда не были, потому что для плеера и gui-то и не нужен - он должен играть в фоне, управляться хоткеями и не занимать место на экране. Из gui нужен только редактор плейлиста. Есть правда кейс 'party mode' когда нужен именно плеер на весь экран с визуализациями и свистелками.
Думаю, код, выбрасывающий исключение всякий раз, когда произойдет что-то неожиданное, сложен для понимания, и его тяжелее поддерживать.
Это утверждение требует доказательства, без которого вся статья не имеет смысла. Мой опыт показывает обратное - только при использовании исключений код будет прозрачным, очевидным и сконцентрированным на том что мы делаем, а не на том что может пойти не так. Код обработки ошибок будет обособлен в ограниченном числе мест на верхнем уровне где мы можем сделать что-то осмысленное, а где-то вообще не нужен - консольное приложение пусть просто упадёт (в Python будет готовый трейс, в C++, ок, придётся обернуть main в try чтобы распечатать what()). В веб бэкенде исключение перехватится на уровне обработки запроса и клиенту вернётся 503. В GUI приложении я бы обернул,например, только целиком код open/save чтобы сказать "не шмогла" и продолжить работу.
Все же подходы с возвратом значений заставляют думать об обработке ошибок в каждой строке, на каждом шаге. Даже если это сделано как в rust - односимвольным оператором, мне все равно надо думать, возвращает ли эта функция голое значение или Result, хочу ли я ? или !, и что будет если сторонний код который я вызываю вызовет panic? Если функция не возвращала ошибку, но начала возвращать, мне придётся менять все её вызовы (в полюсах есть похожая проблема с noexcept, но он про оптимизацию и его можно, а в публичных интерфейсах, пожалуй, и нужно не использовать.
Но да, в редких случаях когда нужно контролировать каждый шаг алгоритма Result с монадическим интерфейсом удобен. В прочем, в языке в котором есть исключения можно без особых проблем обернуться одно в другое (может быть с точностью до производительности).
Это, возможно, только верхушка проблем с JIT. С год назад я чинил в 13.0 устойчивое падение бэкенда в llvmjit на FreeBSD. В двух словах, там оказалось что LLVM не умеет инлайнить функции с обращениями к thread local storage, а под FreeBSD в TLS хранятся параметры локали, которые используются из функций типа isspace(). isspace(), в свою очередь, используется много где в коде PostgreSQL, в частности при конвертации типов (чтобы пропустить не значащие пробелы), например при конвертации текста/json в bool (boolin()), где оно, собственно и падало. В Linux, видимо, isspace() устроена по другому, поэтому там это так сильно не стреляло.
Так вот, оказалось что testsuite постгреса не прогонялся с JIT вообще (он даже не собирался с поддержкой JIT; ЕМНИП там код должен был собираться два раза - по классике для обычных вызовов и в объектный код LLVM для JIT). Не знаю, может быть с тех пор это починили, но непокрытую тестами фичу я бы на месте авторов постгреса не стал выкатывать.
В целом я не понимаю людей которые обновляют major version на проде через две недели после выхода и на след. день после релиза облачного провайдера. Другое поколение. Можно обозвать меня бумером - так оно и есть.
А что вы предлагаете, ждать и надеяться что кто-то наступит на тот же баг что случится у вас, его зарепортят и починят? Сколько именно нужно ждать? Придерживаться ли ритуалов вроде "никогда не ставить x.0"? Какие это даст гарантии? Может вообще не обновляться?
И да, если погонять нагрузку в staging подольше, то вероятность обнаружения ошибки увеличивается.
Вот же правильный ответ, только на stg можно гонять следующий релиз задолго до собственно релиза. А если на stg под рабочей нагрузкой идеально работает хоть альфа, что мешает выкатить хоть альфу в прод если от этого будет профит? Тем более что можно выкатить на 10% кластера и мгновенно откатить?
В прошлом веке не было инструментов позволяющих одной кнопкой сделать копию прода, выкатить туда любую версию любого сервиса, и убедиться что всё это ожидаемо работает, а в случае проблем безболезненно откатиться. Поэтому ждали "стабилизации" и всё равно тряслись при каждом мажорном обновлении. Сейчас это бессмысленно - при современном подходе к разработке и деплою можно хоть из git всё собирать с минимальным риском.
А последнее время райф вообще оставляет ощущение поделки либо помирающей конторы.
Например, чат в online.raiffeisen.ru через который делаются всякие нужные вещи уже с год не работает в firefox, потому что текст сжимается до колонки в 10 пикселей.
Сейчас воспользовался другим чатом chat.raiffeisen.ru, чтобы туда войти достаточно ввести имя и телефон, при этому СМС подтверждения не требуется. Захожу, прошу открыть счёт, ответ "хорошо, откроем счёт, скинем реквизиты на почту, ваша почта xxx@yyy актуальна?". То есть первому неавторизованному встречному сходу как минимум сливают мою личную почту. Скорее всего наинженерить и что-то посерьёзнее.
Потом, они подозрительным образом позакрывали все отделения и банкоматы в округе (районы Лосиноостровский, Южное Медведково Москвы), а те что остались работают через раз. По карте хорошо видно что на большей части Москвы банкоматов в пешей доступности не осталось.
Уже пару лет тестирую mastodon, и пока это вызывает только лютую печаль.
Нет никакой возможности фильтровать полезный контент. Из трёх упомянутых лент:
Глобальная бесполезна, потому что это сплошной поток (и уже довольно значительного объёма) нерелевантного мусора. Ото всех подряд, обо всём подряд (хотя в основном ни о чём, т.е. shitposts), на всех подряд языках (фильтр по языку есть, но не похоже чтобы он работал).
Локальная бесполезна, потому что отсекает большую часть постов по синтетическому признаку (принадлежности к инстансу). Хотя она и может иметь более высокую среднюю релевантность если вы выберете правильный тематический инстанс. Но, во-первых, обычно на тематических инстансах явно не запрещены другие темы и всё равно на инстансе про СПО получаем фотки еды и домашних животных и обсуждение ковида, во-вторых, что делать если мне интересно несколько тем, не плодить же аккаунты?
Подписки на пользователей бесполезны потому что даже если подписаться на кого-нибудь из-за качественного интересного поста, следующим постом обязательно пойдёт еда, политика, ковид, superbowl и прочая ерунда.
Можно использовать разве что средства фильтрации на хэштегам, которые прикручены сбоку, не во всех клиентах, везде реализованы по-разному, везде неудобно и не синхронизируются. Скажем, в web интерфейсе мастодона это возможно только в "advanced" режиме, который представляет собой кошмарное с точки зрения юзабилити решение из нескольких колонок. В обычном режиме с единой лентой фильтровать по хэштегам нельзя. Даже с фильтрацией по хэштегам в ленту будет попадать мусор, поэтому сверху это посыпается mute сотен аккаунтов и целых инстансов и ещё (по всей видимости родными мастодоновскими) исключающими фильтрами по кейвордам, которые тоже не очень понятно работают ли как ожидается.
К платформе тоже есть вопросы. Пока впечатление такое что цензура там куда реальнее чем в централизованных сетях, при этом злее и неадекватнее. Кто-то позволил себе не поддержать BLM/SJW, сразу начинаются призывы (а к слову, неадекватных SJW которых забанили в других сетях в fediverse пруд пруди) забанить (defederate) весь его инстанс. И админам приходится дефедерироваться, иначе начинают дефедерироваться уже с ними.
В общем, для меня взаимодействие с сетью сводится к когда прям совсем нечего делать полистать жёсткую выжимку по хэштегам и ничего интересного там не найти. Ну или написать что-то вникуда, может пара человек увидит. Интересно было бы узнать про отличный от моего опыт. Ещё всегда было интересно, сильно ли это отличется от twitter, или там такая же помойка.
Мне кажется что чистый разум преследует две цели — творение и исследование, и при отказе от любой из них получается бессмысленный деградант. Тут конечно можно поспорить что совокупность творящих разумов является неиссякаемым источником неисследованного друг для друга, но всё-таки как ни крути она будет ограничена возможностями и самих разумов, и среды их существования. Поэтому реальность должна быть притягательна как сама по себе, так и потенциальной возможностью существования надреальностей.
По этой же причине оставаться в нашей солнечной системе такой цивилизации не имеет смысла. Наверняка есть какой-то баланс вычислительной мощности и потребляемой энергии по достижении которого наращивание "железа" перестаёт быть целесообразным, доступ к большому объёму материи становится не нужен, и остаётся затариться дейтерием или там антивеществом и полететь туда где интереснее. А с собой взять достаточно данных о родном мире чтобы не понадобилось возвращаться.
Это очень хорошо, сказал он, потому что теперь можно использовать BigQuery на индексе репозитория!
Это же очень давно можно, и это большая проблема, потому что полные метаданные о пакетах в PyPI можно получить только через проприетарное гугловское API, требующее ещё и наличия Google аккаунта. Для Repology, например, мне пришлось написать сервис который собирает частичные метаданные из нескольких разнородных, полурабочих и частично deprecated API, вместо того чтобы просто скачать json, как это делается для других поддерживаемых коллекций модулей включая RubyGems, crates.io, CPAN, CRAN, MELPA, Hackage, LuaRocks и т.д.
Очень неприятно что постулируется первичность работы и вторичность "pet-проекта". Как насчёт того что, наоборот, основной деятельностью талантливого разработчика является развитие собственных проектов, а работа — всего лишь средство поддержки этой деятельности?
Кстати, чтобы проще было попасть в пакетные репозитории неплохо было бы ответственнее относиться к релизам. А у вас в cmake версия 2.2.0, а в тэгах какое-то alpha-17sep20.
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 и подобными расширениями.
Это не имеет значения потому что есть
catch(...), а вообще код который кидает что-то не унаследованное отstd::exceptionможно смело приравнивать к ill-formed.Помню sonique, про него ещё ходили слухи что в нем качество звучания лучше из-за собственного декодера. Но ни winamp ни sonique удобными с точки зрения gui никогда не были, потому что для плеера и gui-то и не нужен - он должен играть в фоне, управляться хоткеями и не занимать место на экране. Из gui нужен только редактор плейлиста. Есть правда кейс 'party mode' когда нужен именно плеер на весь экран с визуализациями и свистелками.
Для Linux их было/есть полно - xmms(2), audacious, qmmp, ещё что-то. Ими не пользуются потому что есть гораздо более удобные mpd и moc.
Нет, не приводит, потому что перехватывается std::exception.
Это утверждение требует доказательства, без которого вся статья не имеет смысла. Мой опыт показывает обратное - только при использовании исключений код будет прозрачным, очевидным и сконцентрированным на том что мы делаем, а не на том что может пойти не так. Код обработки ошибок будет обособлен в ограниченном числе мест на верхнем уровне где мы можем сделать что-то осмысленное, а где-то вообще не нужен - консольное приложение пусть просто упадёт (в Python будет готовый трейс, в C++, ок, придётся обернуть main в try чтобы распечатать what()). В веб бэкенде исключение перехватится на уровне обработки запроса и клиенту вернётся 503. В GUI приложении я бы обернул,например, только целиком код open/save чтобы сказать "не шмогла" и продолжить работу.
Все же подходы с возвратом значений заставляют думать об обработке ошибок в каждой строке, на каждом шаге. Даже если это сделано как в rust - односимвольным оператором, мне все равно надо думать, возвращает ли эта функция голое значение или Result, хочу ли я ? или !, и что будет если сторонний код который я вызываю вызовет panic? Если функция не возвращала ошибку, но начала возвращать, мне придётся менять все её вызовы (в полюсах есть похожая проблема с noexcept, но он про оптимизацию и его можно, а в публичных интерфейсах, пожалуй, и нужно не использовать.
Но да, в редких случаях когда нужно контролировать каждый шаг алгоритма Result с монадическим интерфейсом удобен. В прочем, в языке в котором есть исключения можно без особых проблем обернуться одно в другое (может быть с точностью до производительности).
Это, возможно, только верхушка проблем с JIT. С год назад я чинил в 13.0 устойчивое падение бэкенда в llvmjit на FreeBSD. В двух словах, там оказалось что LLVM не умеет инлайнить функции с обращениями к thread local storage, а под FreeBSD в TLS хранятся параметры локали, которые используются из функций типа isspace(). isspace(), в свою очередь, используется много где в коде PostgreSQL, в частности при конвертации типов (чтобы пропустить не значащие пробелы), например при конвертации текста/json в bool (boolin()), где оно, собственно и падало. В Linux, видимо, isspace() устроена по другому, поэтому там это так сильно не стреляло.
Так вот, оказалось что testsuite постгреса не прогонялся с JIT вообще (он даже не собирался с поддержкой JIT; ЕМНИП там код должен был собираться два раза - по классике для обычных вызовов и в объектный код LLVM для JIT). Не знаю, может быть с тех пор это починили, но непокрытую тестами фичу я бы на месте авторов постгреса не стал выкатывать.
А что вы предлагаете, ждать и надеяться что кто-то наступит на тот же баг что случится у вас, его зарепортят и починят? Сколько именно нужно ждать? Придерживаться ли ритуалов вроде "никогда не ставить x.0"? Какие это даст гарантии? Может вообще не обновляться?
Вот же правильный ответ, только на stg можно гонять следующий релиз задолго до собственно релиза. А если на stg под рабочей нагрузкой идеально работает хоть альфа, что мешает выкатить хоть альфу в прод если от этого будет профит? Тем более что можно выкатить на 10% кластера и мгновенно откатить?
В прошлом веке не было инструментов позволяющих одной кнопкой сделать копию прода, выкатить туда любую версию любого сервиса, и убедиться что всё это ожидаемо работает, а в случае проблем безболезненно откатиться. Поэтому ждали "стабилизации" и всё равно тряслись при каждом мажорном обновлении. Сейчас это бессмысленно - при современном подходе к разработке и деплою можно хоть из git всё собирать с минимальным риском.
А последнее время райф вообще оставляет ощущение поделки либо помирающей конторы.
Например, чат в online.raiffeisen.ru через который делаются всякие нужные вещи уже с год не работает в firefox, потому что текст сжимается до колонки в 10 пикселей.
Сейчас воспользовался другим чатом chat.raiffeisen.ru, чтобы туда войти достаточно ввести имя и телефон, при этому СМС подтверждения не требуется. Захожу, прошу открыть счёт, ответ "хорошо, откроем счёт, скинем реквизиты на почту, ваша почта xxx@yyy актуальна?". То есть первому неавторизованному встречному сходу как минимум сливают мою личную почту. Скорее всего наинженерить и что-то посерьёзнее.
Потом, они подозрительным образом позакрывали все отделения и банкоматы в округе (районы Лосиноостровский, Южное Медведково Москвы), а те что остались работают через раз. По карте хорошо видно что на большей части Москвы банкоматов в пешей доступности не осталось.
Уже пару лет тестирую mastodon, и пока это вызывает только лютую печаль.
Нет никакой возможности фильтровать полезный контент. Из трёх упомянутых лент:
Можно использовать разве что средства фильтрации на хэштегам, которые прикручены сбоку, не во всех клиентах, везде реализованы по-разному, везде неудобно и не синхронизируются. Скажем, в web интерфейсе мастодона это возможно только в "advanced" режиме, который представляет собой кошмарное с точки зрения юзабилити решение из нескольких колонок. В обычном режиме с единой лентой фильтровать по хэштегам нельзя. Даже с фильтрацией по хэштегам в ленту будет попадать мусор, поэтому сверху это посыпается mute сотен аккаунтов и целых инстансов и ещё (по всей видимости родными мастодоновскими) исключающими фильтрами по кейвордам, которые тоже не очень понятно работают ли как ожидается.
К платформе тоже есть вопросы. Пока впечатление такое что цензура там куда реальнее чем в централизованных сетях, при этом злее и неадекватнее. Кто-то позволил себе не поддержать BLM/SJW, сразу начинаются призывы (а к слову, неадекватных SJW которых забанили в других сетях в fediverse пруд пруди) забанить (defederate) весь его инстанс. И админам приходится дефедерироваться, иначе начинают дефедерироваться уже с ними.
В общем, для меня взаимодействие с сетью сводится к когда прям совсем нечего делать полистать жёсткую выжимку по хэштегам и ничего интересного там не найти. Ну или написать что-то вникуда, может пара человек увидит. Интересно было бы узнать про отличный от моего опыт. Ещё всегда было интересно, сильно ли это отличется от twitter, или там такая же помойка.
Мне кажется что чистый разум преследует две цели — творение и исследование, и при отказе от любой из них получается бессмысленный деградант. Тут конечно можно поспорить что совокупность творящих разумов является неиссякаемым источником неисследованного друг для друга, но всё-таки как ни крути она будет ограничена возможностями и самих разумов, и среды их существования. Поэтому реальность должна быть притягательна как сама по себе, так и потенциальной возможностью существования надреальностей.
По этой же причине оставаться в нашей солнечной системе такой цивилизации не имеет смысла. Наверняка есть какой-то баланс вычислительной мощности и потребляемой энергии по достижении которого наращивание "железа" перестаёт быть целесообразным, доступ к большому объёму материи становится не нужен, и остаётся затариться дейтерием или там антивеществом и полететь туда где интереснее. А с собой взять достаточно данных о родном мире чтобы не понадобилось возвращаться.
Это же очень давно можно, и это большая проблема, потому что полные метаданные о пакетах в PyPI можно получить только через проприетарное гугловское API, требующее ещё и наличия Google аккаунта. Для Repology, например, мне пришлось написать сервис который собирает частичные метаданные из нескольких разнородных, полурабочих и частично deprecated API, вместо того чтобы просто скачать json, как это делается для других поддерживаемых коллекций модулей включая RubyGems, crates.io, CPAN, CRAN, MELPA, Hackage, LuaRocks и т.д.
Очень неприятно что постулируется первичность работы и вторичность "pet-проекта". Как насчёт того что, наоборот, основной деятельностью талантливого разработчика является развитие собственных проектов, а работа — всего лишь средство поддержки этой деятельности?
Кстати, чтобы проще было попасть в пакетные репозитории неплохо было бы ответственнее относиться к релизам. А у вас в cmake версия
2.2.0, а в тэгах какое-тоalpha-17sep20.Попали уже несколько лет назад (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).