пятница, 1 февраля 2019 г.

[prog.sadness] Buckaroo: заменить одно ненужно на другое :(

Наглядный пример того, как выбросить одно ненужно и заменить его другим ненужно: https://github.com/LoopPerfect/buckaroo/releases/tag/v2.0.0

Есть такая система сборки для C++ проектов: Buck.
И к ней система управления зависимостями Buckaroo.
Кажется, от чуваков из Facebook.

Так вот, раньше эта система управлениями зависимостями была написана на Java. Соответственно, хочешь использовать для своих C++ проектов Buckaroo -- ставь себе JRE.

А теперь это все добро взяли и переписали на чем?

На .NET.

Инсталлятор этой прелести для Windows весит 35Mb, для Linux-а и Mac-а чуть больше 65Mb. Для FreeBSD готового инсталлятора нет.

Что в этом всем печальнее всего?

А то, что по своей задумке и Buck, и особенно Buckaroo, наиболее интересные и вменяемые из всего, что сейчас развивается в мире C++ инструментария, включая CMake, build2, meson, vcpkg, Conan, Hunter и пр. А уж Bockaroo, так это чуть ли не доведенный до своего логического завершения MxxRu::externals. Все ИМХО, конечно же.

6 комментариев:

  1. А чем плох .NET или Java?
    Размер сегодня это ерунда.
    К тому же в .NET Core 3 можно создать единственный exe файл при этом именно удобную разработку.
    Разрабатывать на плюсах только для разработки на плюсах это сегодня на мой взгляд не имеет смысла.

    ОтветитьУдалить
  2. @NN
    > А чем плох .NET или Java?

    Давай сюда еще добавим Python и Haskell. Не, у а че. Мне для сборки софта на C++ нужно иметь приблуды на 5-10 языках, которые будут весить под гигабайт.

    > Размер сегодня это ерунда.

    Ну если сборка делается в Docker-е, то размер имеет значение.

    ОтветитьУдалить
  3. Ну вот для Mercurial нужен Python, а для Mxx Ruby.
    Тебя же это не смущает ?

    Как только функционал на плюсах достаточно развит, то и размер получаем соответствующий.
    30МБ для докера размером в 70МБ это конечно немало, а для докера на 600МБ не так много.

    В принципе можно через .NET Core 3 ужать в один файл а при желании задействовать .NET Native.
    Лучше пусть сделают хоть что-то чем будет удобно пользоваться , а там когда рынок захватят, переписывают на что угодно, а иначе работать будут много а пользы ноль.

    ОтветитьУдалить
  4. @NN

    Ну вот Mercurial на Python и Conan на Python. Было бы Buckaroo на Python было бы проще.

    ОтветитьУдалить
  5. Если в итоге додумаются упаковать всё в один исполняемый файл то какая будет разница ?

    ОтветитьУдалить
  6. @NN

    Если build-tool на Питоне будет распространяться как один exe-шник?

    Ну, в общем-то, это хорошо для случая, если build-tool просто работает и тебе никогда не приходится в его потроха заглядывать, чтобы разобраться с какой-нибудь проблемой или непонятным поведением.

    ОтветитьУдалить