Удивлён, кстати, что где-то Linux уступает BSD-системам. На моей практике было ровно наоборот. Хотя и у меня задачи совсем другие были... Около-скриптового характера. Несколько примеров из того что вспомню:
BSD-шный date не поддерживает %N, а значит отсутствует простая и быстрая возможность получать нано- или хотя-бы миллисекундное разрешение времени в shell
BSD-шный awk гораздо медленнее Gawk
В BSD нет линуксового /dev/shm - файловая система в RAM - удобно для быстрого создания временных файлов
В BSD нет /dev/stderr, /dev/stdin, /dev/stdout
Коробочный bash в macOS гораздо древнее актуального, а во Free он даже не установлен по дефолту
Добавьте своё или поправьте меня по пунктам выше👆
Короче, для себя сделал вывод, что для разработчика Linux поприятнее, чем macOS/FreeBSD. Да и вообще GNU-окружение по сравнению с BSD-аналогами.
Я разделяю противоположный подход и опираюсь при этом на философию Unix, и принципы "Less is More" и "Worse is Better". Не вижу, почему их нельзя применить и для подобных инструментов.
Ну пожалуйста, берите. Ваш выбор. Опять таки, я в который раз не понимаю какую мысль Вы пытаетесь донести. Что мой инструмент не нужен, потому что написан на баш (нет), а не на Питон, потому что в нем есть вещи, которые Вам не нравятся, потому что он очень легковесен, а это НЕ является преимуществом, и что можно на cmake сделать всё то же самое?
Если да, то Вы меня убедили - Вам не нужно использовать этот инструмент, и за сим обсуждение в этой ветке можно закрыть, как подошедшее к логическому концу.
Если нет, то просьба уточнить предмет Вашего несогласия 🙂
Я не очень понимаю идею делать отдельную программу таск-раннер
Предположим для простоты вы хотите иметь три задачи на проекте: test, build, deploy. Имеем вопрос: написать три разных скрипта test.sh, build.sh, deploy.sh или один скрипт run.sh (будет запускаться как ./run.sh command). Рассмотрим эти варианты подробнее.
Несколько разных скриптов замусоривают проект. Надо все документировать в README. А deploy.sh может быть ./deploy.sh dev и ./deploy.sh prod. Тоже все в README описать. В случае таск-раннера в README достаточно добавить одну строку Запустите ./makesure -l.
В случае run.sh подхода вам надо писать некий необходимый бойлерплейт для разбора аргументов и роутинга на команды, вывод списка доступных команд, и т.д. И повторять эту работу для каждого нового проекта. Однако, если подумать run.sh это уже и есть такой себе таск-раннер только гораздо менее фичастый. Ну собственно и вот. Подход внешнего таск-раннера позволяет разделить декларативное описание бизнес-задач и движка их исполнения. Плюс, разные встроенные возможности, скажем замер времени исполнения каждой цели, настройки трейсинга и т.п.
Ещё интереснее дело, если учесть зависимости между задачами. Скажем, чтобы протестировать проект, надо его сперва собрать, т.е. надо в вызов test добавить build. So far so good. Теперь, чтобы развернуть приложение, надо его собрать и протестировать. Добавляем в deploy вызовы на build и test. Упс! Теперь у нас на деплой билд будут запускаться дважды! Понимаю, что пример утрирован, но и реальный набор задач и зависимостей между ними может быть сложнее. А таск-раннер обеспечивает run-only-once семантику для зависимостей.
Ну это Вы смотрите с точки зрения разработчика инструмента. Попробуйте взглянуть с точки зрения пользователя. Тем не менее по пунктам:
Справедливости ради, разработка ведётся на AWK в соответствующем файле, а конечный shell-скрипт собирается в момент релиза. Что же касается разработки на AWK, то так уж получилось, что ваш покорный слуга написал и поддерживает соответствующий плагин https://github.com/xonixx/intellij-awk под IntelliJ IDEA и другие IDE JetBrains. Поэтому разрабатывать вполне себе приятно.
Синтаксис является подмножеством синтаксиса shell (хоть и с другой семантикой). Поэтому подсветка shell для Makesurefile должна работать в любой IDE. Например GitHub валидно подсвечивает синтаксис: https://github.com/xonixx/makesure/blob/main/Makesurefile. Да это не идеал, но вполне приятно.
Возможно и так. Хотя по поводу директивы @reached_ifhttps://github.com/xonixx/makesure#reached_if я бы поспорил. Однако, сила этого инструмента не в какой-то конкретной киллер-фиче, а в той, как мне кажется удачной и минималистичной комбинации вроде бы простых фич, которую удалось найти.
В данном случае подразумеваемся легкость установки инструмента. Напоминаю, что в makesure O(N) разработчикам на проекте вообще не придётся ничего ставить.
Этот скрипт скачает при первом запуске значительно больше, чем весит.
А это плохо? Вы же сами написали что дело не в байтах.
Конечно, автоматизировать сборку Хромиума таким образом будет close to unreal. Но что-то попроще очень даже можно. Например, в моем случае прогонка тестов зависит от установки инструмента тестирования https://github.com/xonixx/makesure/blob/main/Makesurefile#L14. Удобно, когда ты up and running сразу после скачивания проекта из репы.
В точку! Я выбрал вариант который, да, труднее разрабатывать но очень просто распространять. Вообще я считаю что для такого инструмента языки с рантаймами (питон/перл/нода/...) исключены. Только компиляторы, производящие статический бинарник или вот так.
Исключение: если task runner на питоне заточен под питон-проекты.
Питон, конечно, доступен везде. Однако известно, что его инфраструктура это сущий ад https://xkcd.com/1987/. Сделать кросс-платформенный самодостаточный дистрибутив программы, написанной на Питоне, особенно если там используется пара-тройка специфичных пакетов, просто ну чудовищно сложно.
У чего угодно другого с портабельностью туго. По моему разумению для такого тула это очень важный показатель. Многопоточность - неплохо но это вотчина именно билд тулов. Подробнее https://github.com/xonixx/makesure#omitted-features
Я верю, что Вы хорошо знаете make и понимаете зачем он нужен. Перечень пунктов выше показывает НЕ то что make зло вообще, а то что make неудобен если использовать его как простой task runner а не как полный build tool (его основная функция). В этом случае некоторые его сильные стороны в качестве build tool становятся "неудобствами".
Ну и отлично! НО! curl, например, это все-таки такой себе серьезный стандарт, можно сказать. Даже в хроме можно скопировать запрос в синтаксисе curl.
А аналоги - они, разумеется, есть. Но, видимо, гораздо менее популярные и используемые. Потому, видимо, и сама Фря так малопопулярна теперь.
Все так, но это не меняет факта. В системе по умолчанию стоит самый каноничный, но самый медленный awk, а не быстрые gawk или mawk
Но по умолчанию я наблюдаю, что у меня в macOS и фре /tmp это диск
Да, тут моя неправда. Сейчас перепроверил и всё работает. Значит, это была другая ошибка. Благодарю.
Все так, но это не менят факта.
Еще вспомнил момент. Во Фре по дефолту нету wget и curl, но есть некий fetch.
Удивлён, кстати, что где-то Linux уступает BSD-системам. На моей практике было ровно наоборот. Хотя и у меня задачи совсем другие были... Около-скриптового характера. Несколько примеров из того что вспомню:
BSD-шный date не поддерживает %N, а значит отсутствует простая и быстрая возможность получать нано- или хотя-бы миллисекундное разрешение времени в shell
BSD-шный awk гораздо медленнее Gawk
В BSD нет линуксового /dev/shm - файловая система в RAM - удобно для быстрого создания временных файлов
В BSD нет /dev/stderr, /dev/stdin, /dev/stdout
Коробочный bash в macOS гораздо древнее актуального, а во Free он даже не установлен по дефолту
Добавьте своё или поправьте меня по пунктам выше👆
Короче, для себя сделал вывод, что для разработчика Linux поприятнее, чем macOS/FreeBSD. Да и вообще GNU-окружение по сравнению с BSD-аналогами.
А что такого. Unsafe прекрасно работает в Java 17. Да и если когда-то смогут выпилить - все равно сделают замену. Уж слишком много на него завязано.
Зависимости как-раз не скрываются а вполне даже декларативно описываются (пример).
У инструмента также есть опция соответствующая для показа зависимостей любой цели:
Я разделяю противоположный подход и опираюсь при этом на философию Unix, и принципы "Less is More" и "Worse is Better". Не вижу, почему их нельзя применить и для подобных инструментов.
Естественно, является.
Ну пожалуйста, берите. Ваш выбор. Опять таки, я в который раз не понимаю какую мысль Вы пытаетесь донести. Что мой инструмент не нужен, потому что написан на баш (нет), а не на Питон, потому что в нем есть вещи, которые Вам не нравятся, потому что он очень легковесен, а это НЕ является преимуществом, и что можно на cmake сделать всё то же самое?
Если да, то Вы меня убедили - Вам не нужно использовать этот инструмент, и за сим обсуждение в этой ветке можно закрыть, как подошедшее к логическому концу.
Если нет, то просьба уточнить предмет Вашего несогласия 🙂
Предположим для простоты вы хотите иметь три задачи на проекте: test, build, deploy. Имеем вопрос: написать три разных скрипта test.sh, build.sh, deploy.sh или один скрипт run.sh (будет запускаться как ./run.sh command). Рассмотрим эти варианты подробнее.
Несколько разных скриптов замусоривают проект. Надо все документировать в README. А deploy.sh может быть
./deploy.sh devи./deploy.sh prod. Тоже все в README описать. В случае таск-раннера в README достаточно добавить одну строкуЗапустите ./makesure -l.В случае run.sh подхода вам надо писать некий необходимый бойлерплейт для разбора аргументов и роутинга на команды, вывод списка доступных команд, и т.д. И повторять эту работу для каждого нового проекта. Однако, если подумать run.sh это уже и есть такой себе таск-раннер только гораздо менее фичастый. Ну собственно и вот. Подход внешнего таск-раннера позволяет разделить декларативное описание бизнес-задач и движка их исполнения. Плюс, разные встроенные возможности, скажем замер времени исполнения каждой цели, настройки трейсинга и т.п.
Ещё интереснее дело, если учесть зависимости между задачами. Скажем, чтобы протестировать проект, надо его сперва собрать, т.е. надо в вызов test добавить build. So far so good. Теперь, чтобы развернуть приложение, надо его собрать и протестировать. Добавляем в deploy вызовы на build и test. Упс! Теперь у нас на деплой билд будут запускаться дважды! Понимаю, что пример утрирован, но и реальный набор задач и зависимостей между ними может быть сложнее. А таск-раннер обеспечивает run-only-once семантику для зависимостей.
Ну это Вы смотрите с точки зрения разработчика инструмента. Попробуйте взглянуть с точки зрения пользователя. Тем не менее по пунктам:
Справедливости ради, разработка ведётся на AWK в соответствующем файле, а конечный shell-скрипт собирается в момент релиза. Что же касается разработки на AWK, то так уж получилось, что ваш покорный слуга написал и поддерживает соответствующий плагин https://github.com/xonixx/intellij-awk под IntelliJ IDEA и другие IDE JetBrains. Поэтому разрабатывать вполне себе приятно.
Из зависимостей только POSIX окружение, которое доступно везде, даже на Win. Так, инструмент регулярно тестируется под Linux, Win, macOS и даже FreeBSD: https://github.com/xonixx/makesure/actions/runs/1646901221
Синтаксис является подмножеством синтаксиса shell (хоть и с другой семантикой). Поэтому подсветка shell для Makesurefile должна работать в любой IDE. Например GitHub валидно подсвечивает синтаксис: https://github.com/xonixx/makesure/blob/main/Makesurefile. Да это не идеал, но вполне приятно.
Возможно и так. Хотя по поводу директивы @reached_if https://github.com/xonixx/makesure#reached_if я бы поспорил. Однако, сила этого инструмента не в какой-то конкретной киллер-фиче, а в той, как мне кажется удачной и минималистичной комбинации вроде бы простых фич, которую удалось найти.
В данном случае подразумеваемся легкость установки инструмента. Напоминаю, что в makesure O(N) разработчикам на проекте вообще не придётся ничего ставить.
А это плохо? Вы же сами написали что дело не в байтах.
Ну в крайности впадать не надо, да? Вы попросили пример подготовки окружения - я дал его.
Публиковать релизы надо всем разработчикам на проекте?
То что удобно автоматизировать - надо автоматизировать. То что не удобно - не надо.
Легковесный инструмент позволяющий делать базовую подготовку окружения удобнее тяжеловесного с зависимостями, разве это не очевидно?
Автоматизация создания релизов на GitHub: https://github.com/xonixx/makesure/releases
Конечно, автоматизировать сборку Хромиума таким образом будет close to unreal. Но что-то попроще очень даже можно. Например, в моем случае прогонка тестов зависит от установки инструмента тестирования https://github.com/xonixx/makesure/blob/main/Makesurefile#L14. Удобно, когда ты up and running сразу после скачивания проекта из репы.
Upd. Также инсталляция различных AWK для прогонки тестов на них https://github.com/xonixx/makesure/blob/main/Makesurefile#L206.
Исполняемый файл представлен исходным кодом https://github.com/xonixx/makesure/blob/main/makesure - поэтому как минимум можно убедиться визуально в отсутствии закладок.
Ну так это как раз можно (и даже нужно) автоматизировать через task runner.
В точку! Я выбрал вариант который, да, труднее разрабатывать но очень просто распространять. Вообще я считаю что для такого инструмента языки с рантаймами (питон/перл/нода/...) исключены. Только компиляторы, производящие статический бинарник или вот так.
Исключение: если task runner на питоне заточен под питон-проекты.
Второй или третий? (шутка)
Питон, конечно, доступен везде. Однако известно, что его инфраструктура это сущий ад https://xkcd.com/1987/. Сделать кросс-платформенный самодостаточный дистрибутив программы, написанной на Питоне, особенно если там используется пара-тройка специфичных пакетов, просто ну чудовищно сложно.
У чего угодно другого с портабельностью туго. По моему разумению для такого тула это очень важный показатель. Многопоточность - неплохо но это вотчина именно билд тулов. Подробнее https://github.com/xonixx/makesure#omitted-features
Никакого стыда!) Инструмент-то молодой, чуть старше года.
Ну если уж вдаваться в детали, там под капотом AWK, кстати гораздо приятнее Bash-а в качестве ЯП 🙂
Я верю, что Вы хорошо знаете make и понимаете зачем он нужен. Перечень пунктов выше показывает НЕ то что make зло вообще, а то что make неудобен если использовать его как простой task runner а не как полный build tool (его основная функция). В этом случае некоторые его сильные стороны в качестве build tool становятся "неудобствами".