Создатели проприетарного программного продукта Biicode (https://www.biicode.com/), в рамках которого развивается менеджер зависимостей и репозиторий пакетов для кода на языках  С/C++, сообщили (http://opensource.com/business/15/1/biicode-open-source-depe...) об утверждении решения по переводу Biicode в разряд свободных проектов. Biicode можно рассматривать в качестве адаптированного для С/C++ аналога систем Pip (Python), Gems (Ruby), cpan (Perl), npm (Node.js) и Pub (Dart), предоставляющих средства для доустановки необходимых для сборки проекта зависимостей, а также поддерживающих репозиторий для публикации пакетов.

По соглашению с инвесторами открытие кода Biicode будет произведено после того как число пользователей сервиса достигнет 10 тысяч. В настоящее время зарегистрировано (https://www.biicode.com/biicode-open-source-challenge) около 2500 аккаунтов. В рамках проекта Ryppl (https://github.com/ryppl/ryppl) уже предпринималась попытка создания подобного инструментария для C++, но проект последние несколько лет находится в заброшенном состоянии.

URL: http://opensource.com/business/15/1/biicode-open-source-depe...
Новость: https://www.opennet.ru/opennews/art.shtml?num=41530

• Принято решение по открытию Biicode, менеджера зависимостей ...,all_glory_to_the_hypnotoad, 15:29 , 24-Янв-15
  • Принято решение по открытию Biicode, менеджера зависимостей ...,Аноним, 16:08 , 24-Янв-15
    • Принято решение по открытию Biicode, менеджера зависимостей ...,all_glory_to_the_hypnotoad, 16:22 , 24-Янв-15
      • Принято решение по открытию Biicode, менеджера зависимостей ...,Вадик, 16:39 , 24-Янв-15
• Принято решение по открытию Biicode, менеджера зависимостей ...,Аноним, 15:33 , 24-Янв-15
• Принято решение по открытию Biicode, менеджера зависимостей ...,Аноним, 15:34 , 24-Янв-15
  • Принято решение по открытию Biicode, менеджера зависимостей ...,Аноним, 17:26 , 24-Янв-15
    • Принято решение по открытию Biicode, менеджера зависимостей ...,й, 21:26 , 24-Янв-15
  • Принято решение по открытию Biicode, менеджера зависимостей ...,Нанобот, 20:44 , 24-Янв-15
    • Принято решение по открытию Biicode, менеджера зависимостей ...,й, 21:27 , 24-Янв-15
      • Принято решение по открытию Biicode, менеджера...,arisu, 21:30 , 24-Янв-15
        • Принято решение по открытию Biicode, менеджера...,й, 13:02 , 25-Янв-15
          • Принято решение по открытию Biicode, менеджера...,arisu, 21:02 , 25-Янв-15
      • Принято решение по открытию Biicode, менеджера зависимостей ...,Аноним, 23:03 , 24-Янв-15
        • Принято решение по открытию Biicode, менеджера зависимостей ...,й, 13:05 , 25-Янв-15
• Принято решение по открытию Biicode, менеджера зависимостей ...,all_glory_to_the_hypnotoad, 15:37 , 24-Янв-15
  • Принято решение по открытию Biicode, менеджера зависимостей ...,Анонимускодер, 22:25 , 24-Янв-15
  • Принято решение по открытию Biicode, менеджера зависимостей ...,Grammar_Nazi, 09:32 , 26-Янв-15
• Принято решение по открытию Biicode, менеджера зависимостей ...,Аноним, 16:18 , 24-Янв-15
  • Принято решение по открытию Biicode, менеджера зависимостей ...,all_glory_to_the_hypnotoad, 16:23 , 24-Янв-15
• Принято решение по открытию Biicode, менеджера зависимостей ...,Аноним, 17:33 , 24-Янв-15
  • Принято решение по открытию Biicode, менеджера зависимостей ...,Аноним, 23:04 , 24-Янв-15
• Принято решение по открытию Biicode, менеджера зависимостей ...,V_ctor, 18:40 , 24-Янв-15
  • Принято решение по открытию Biicode, менеджера зависимостей ...,Аноним, 20:13 , 24-Янв-15
  • Принято решение по открытию Biicode, менеджера зависимостей ...,bav, 20:14 , 24-Янв-15
  • Принято решение по открытию Biicode, менеджера зависимостей ...,anonymous, 13:05 , 17-Авг-15
• Принято решение по открытию Biicode, менеджера зависимостей ...,kravich, 04:32 , 25-Янв-15
• Принято решение по открытию Biicode, менеджера зависимостей ...,Аноним, 04:52 , 25-Янв-15
  • Принято решение по открытию Biicode, менеджера зависимостей ...,Аноним, 10:44 , 25-Янв-15
• Принято решение по открытию Biicode, менеджера зависимостей ...,Куяврег, 13:35 , 25-Янв-15
  • Принято решение по открытию Biicode, менеджера зависимостей ...,Ordu, 22:28 , 25-Янв-15
    • Принято решение по открытию Biicode, менеджера зависимостей ...,all_glory_to_the_hypnotoad, 00:05 , 26-Янв-15
      • Принято решение по открытию Biicode, менеджера зависимостей ...,Ordu, 02:13 , 26-Янв-15
    • Принято решение по открытию Biicode, менеджера зависимостей ...,Куяврег, 00:17 , 28-Янв-15
      • Принято решение по открытию Biicode, менеджера зависимостей ...,Ordu, 00:37 , 28-Янв-15

> Biicode можно рассматривать в качестве адаптированного для С/C++ аналога систем Pip (Python), Gems (Ruby), cpan (Perl), npm (Node.js) и Pub (Dart)

Совсем люди ебанулись.

Что, ты не хочешь вместо 1 пакетного манагера использовать 20 разных? Ну так не пользуйся виндой, а то козленочком станешь..

дебил, это не пакетный менеджер. И это гогно уже по факту второе.

А что было первым?
Я как-то упустил...

В условиях того, что "индусы" клонируют библиотеку и вносят в нее правку, это может быть интересным.

Для молодёжи ведь есть Go с подобной хренью. А олдскульщики С/C++ все равно не будут этим пользоваться.

в Go нет изкоробочного менеджера зависимостей. Там есть только команда "go get", клонирующая указанный репозиторий в папку $GOPATH/src

> "go get", клонирующая указанный репозиторий в папку $GOPATH/src

А также его зависимости, и всё это собирает. Вполне себе катит в роли

> изкоробочного менеджера зависимостей

>А олдскульщики С/C++ все равно не будут этим пользоваться

вот-вот. суровые с/с++-разработчики тридцать лет обходились без такого, вряд ли сейчас они оценят этот гламур

> вот-вот. суровые с/с++-разработчики тридцать лет обходились без такого, вряд ли сейчас
> они оценят этот гламур

Да они и без интернета обходились, копируя библиотеки в проект с дискеты. Хотите вернуться в эти времена?

> Да они и без интернета обходились, копируя библиотеки в проект с дискеты.
> Хотите вернуться в эти времена?

судя по тому, что творится с интернетами, которые с бешеной скоростью засираются хипстерами… идея выглядит уже не совсем бредовой.

аргументация на уровне "книги дарьи донцовой плохие, давайте запретим и сожжем все книги"

ты-то сам что в интернете тогда делаешь, хипстор?

дураков типа тебя пинаю.

> Да они и без интернета обходились,

Прикинь, в отличие от хипстоты у них не падает вообще все если сеть недоступна :).

>> Да они и без интернета обходились,
> Прикинь, в отличие от хипстоты у них не падает вообще все если
> сеть недоступна :).

пользователи svn в треде?

Вообще какое-то невменяемое дерьмище вроде пыховских костылей:

> #include "google/gtest/gtest.h"
> You don’t need “googletest” in your system, it is already in biicode
> bii find It looks for the required libraries in biicode, in this case, googletest. Once found, it downloads the required source code files into one folder of your project and configures everything.

Зашибись.. А если случайно произойдёт наложение имён, то оно похерит проект, или просто будет скачивать всякое гогнище в проект.

Вердикт: закопать вместе с авторами в безимянной могиле.

> Вообще какое-то невменяемое дерьмище вроде пыховских костылей:

Скачает что-то, какой-то версии и поместит это в какой-то каталог. Совсем мозги скурили.

в безымянной

хочу это.
Зарегистрировался

а теперь ретвитни, сделай селфи себя с лого bii и не забудь написать об этом псто в fb

кстати создатель Ruby Gems сейчас пилит Cargo для Rust, и это уже очень крутая вещь. Взять хотя бы воспроизводимые сборки.

> кстати создатель Ruby Gems сейчас пилит Cargo для Rust,

Хорошее название, намекает про детишек с Cargo-культом и модными языками. И софтом из бамбуковых палок.

Объясните, это что-то типа мавена под жабу?

да, только в мавене зависимости прописываются в отдельном конфиге, а эта тулза парсит инклюды

> Объясните, это что-то типа мавена под жабу?

Нет это что-то будет ломать проект если библиотека обновится.

Это типа maven-репозитория. Зависимости по-другому разруливаются.

What's pip? A package manager. How do I get it? Use easy_install. What's easy_install? A package manager. How do I get it? Use apt. (c)

И как мы без этогого жили раньше?

И дальше будем жить. Ибо 10 штук пользователей им никогда не достичь, а это условие открытия.

дело идёт к тому, что на системные зависимости и пакетный менеджер всем будет наплевать. ничего не напоминает? некую систему, где библиотеки размещены в строгом порядке "кто где наср#$%л", каждая софтина имеет свой инсталлятор, свой обновлятор (если имеет), тащит за собой то, к чему её приколотили гвоздями.

выглядит как линуксокапец, но оптимизм внушает две вещи.
- ушлёпки с таким стилем программирования написать под несколько дистров не осиливают.
- фрагментация дистров оставляет варианты для тех, кому не надо из системы делать отхожее место.

Вы слишком поспешно переходите к выводам. Пакетные системы, функционирующие параллельно с системным пакетным менагером, существуют очень давно. Вспомнить тот же autoconf/automake. И унифицированная система сборки для, допустим, проектов на C++ может оказаться весьма удобной для строителей дистрибутивов. Ну, во-всяком случае, примеряя всё это к gentoo, я скажу, что можно конечно запилить пакетный менагер, которым неудобно пользоваться из ебилда и проще реализовать всю логику сборки и инсталляции заново, но если есть хотя бы 700 граммов мозга и общая эрудиция в отношении методов распространения софта в *nix системах, то вполне возможно создать пакетный менагер, который будет реальным подспорьем для мейнтейнеров дистрибутивов, а не чем-то в стиле "не пришей кобыле хвост." Да и для меня оно может оказаться удобным, в том смысле, что чем проще ебилды, тем проще их править, если мне вдруг потребовалось что-то особенное -- это значит что мне меньше придётся ставить всякого дерьма в обход emerge в домашнюю директорию или в /usr/local.

Чтобы делать какие-либо выводы из новости, надо подождать и посмотреть. Не знаю как вы, а я ничего не знаю об этой системе сборки. Я даже по ссылкам на офсайт не переходил, чтобы почитать страничку озаглавленную как About или как WTF, потому что более чем уверен, что ещё не время для выводов и к разработке на C++ я не имею никакого отношения. Но если вы знаете больше, и это больше действительно выглядит ужасно, то не стесняйтесь, поделитесь с нами.

> Пакетные системы, функционирующие параллельно с системным пакетным менагером, существуют очень давно. Вспомнить тот же autoconf/automake

Идиот безмозглый, autotools это не пакетная система.

>> Пакетные системы, функционирующие параллельно с системным пакетным менагером, существуют очень давно. Вспомнить тот же autoconf/automake
> Идиот безмозглый, autotools это не пакетная система.

Расскажите ещё что-нибудь об autotools, у вас очень занимательно выходит.

> Вы слишком поспешно переходите к выводам. Пакетные системы, функционирующие параллельно
> с системным пакетным менагером, существуют очень давно. Вспомнить тот же autoconf/automake.

o_O по моим сведениям использование autoconf/automake не приводит к появлению в системе библиотек, неизвестных пакетному менеджеру системы, сами не ведут никакого учёта установленного и сторого говоря пакетным менеджером не являются. во всяком случае в портах и портежах это далеко не так. Я не спорю, что при горячем желании это можно сделать, но пока я не видел таких решений. А вот упомянутые pip/gems/cpan - видел, и применяются они ровно так, как не надо.

>[оверквотинг удален]
> к gentoo, я скажу, что можно конечно запилить пакетный менагер, которым
> неудобно пользоваться из ебилда и проще реализовать всю логику сборки и
> инсталляции заново, но если есть хотя бы 700 граммов мозга и
> общая эрудиция в отношении методов распространения софта в *nix системах, то
> вполне возможно создать пакетный менагер, который будет реальным подспорьем для мейнтейнеров
> дистрибутивов, а не чем-то в стиле "не пришей кобыле хвост." Да
> и для меня оно может оказаться удобным, в том смысле, что
> чем проще ебилды, тем проще их править, если мне вдруг потребовалось
> что-то особенное -- это значит что мне меньше придётся ставить всякого
> дерьма в обход emerge в домашнюю директорию или в /usr/local.

...и с этим сложно спорить. Да, теоретически можно так и сделать. И если кто-то реализует - вполне возможно кому-то такое понадобится. И если будет работать отлично - так ещё один source-based с унифицированной системой сборки, она же пакетный менеджер - не останется без аудитории. Но пока это теоретические выкладки.

> Но если вы знаете больше, и это больше действительно выглядит ужасно, то не стесняйтесь, поделитесь с нами.

Степень ужасности зависит ровно от применения. Сам молоток не является ужасным, но если его держат за боёк и забивают рукоятью - это ужасно. Так что если оно будет применяться в качестве единственного менеджера пакетов - это нормально (хотя и бесполезно для остальных). Если подобно cpan/gems в портах/портежах - это выглядит ужасно. Да, и будем честными, не только выглядит. Это и есть ужасно.

>> Вы слишком поспешно переходите к выводам. Пакетные системы, функционирующие параллельно
>> с системным пакетным менагером, существуют очень давно. Вспомнить тот же autoconf/automake.
> o_O по моим сведениям использование autoconf/automake не приводит к появлению в системе
> библиотек, неизвестных пакетному менеджеру системы, сами не ведут никакого учёта установленного
> и сторого говоря пакетным менеджером не являются. во всяком случае в
> портах и портежах это далеко не так. Я не спорю, что
> при горячем желании это можно сделать, но пока я не видел
> таких решений. А вот упомянутые pip/gems/cpan - видел, и применяются они
> ровно так, как не надо.

Вы видели как порты и портежи используют pip/gems/cpan? Примерно так же как и autoconf/automake. Нет, я понимаю, что вас раздражает -- я назвал autoconf/automake пакетным менагером, вы же при этом считаете, что отслеживание зависимостей, установленных файлов, конфликтов между файлами и прочие функции -- неотъемлимыми атрибутами пакетного менагера, без которых он совсем не менагер. Мы можем поспорить на этот счёт, если вы хотите, но это будет терминологический спор, исход которого никак не изменит истинности/ложности того, что было сказано мною -- в худшем случае, мне придётся подредактировать то моё сообщение и заменить там слова "пакетный менагер" на какое-то другое собирательное слово/слова, которые будут означать множество софта, включающее в себя и pip/gems и autotools.
Мне совершенно не хочется спорить о какой-то туфте типа слов. Слова -- это просто способ сотрясать воздух, спорить из-за них глупо. Давайте считать, что я проиграл спор, но при одном условии: дайте мне этот собирательный термин, который я смогу воткнуть вместо "пакетного менагера". Я отредактирую то своё сообщение, приведу его к нераздражающему вас виду, и ещё оставлю покаянный постскриптум, с пояснением внесённой правки.

> ...и с этим сложно спорить. Да, теоретически можно так и сделать. И
> если кто-то реализует - вполне возможно кому-то такое понадобится. И если
> будет работать отлично - так ещё один source-based с унифицированной системой
> сборки, она же пакетный менеджер - не останется без аудитории. Но
> пока это теоретические выкладки.

Практически, всё сведётся к тому, что появится ещё один eclass, который позволит в две строчки кода укладывать ебилды для софта использующего biicode. Может быть даже появятся скрипты, которые будут генерировать эти самые ебилды, на основании конфига проекта. Неплохо было бы, м? Держать /usr/local/portage в когерентном состоянии стало бы ещё проще.

> Степень ужасности зависит ровно от применения. Сам молоток не является ужасным, но
> если его держат за боёк и забивают рукоятью - это ужасно.
> Так что если оно будет применяться в качестве единственного менеджера пакетов
> - это нормально (хотя и бесполезно для остальных). Если подобно cpan/gems
> в портах/портежах - это выглядит ужасно. Да, и будем честными, не
> только выглядит. Это и есть ужасно.

Подробнее можно? Вас не устраивает то, что ebuild'ы для ruby-софта оказываются обёртками над gem? А когда эти ebuild'ы -- обёртки над autoconf/automake? Это тоже не нравится? Почему?

Мне кажется это замечательно -- есть куча средств сборки и установки софта, и ebuild при таком подходе становится мета-средством установки софта, которое унифицирует интерфейс, прячет различия, приводит всё к общему знаменателю. Собственно то, чем этот ebuild и являлся все эти годы, начиная с момента своего рождения.