Nix как менеджер зависимостей для C++

[@akalend]

замечательная статья, спасибо

[@lockywolf]

Хм. Мне всегда казалось, что менеджера пакетов для С++ нет ровно по той причине по которой он есть для все других языков. Для всех других языков менеджер пакетов устанавливает только пакеты, написанные на этих языках.
Ну, в некотором смысле такой «инструмент поддержки инфраструктуры». Нужна тебе библиотека — напиши «cpan ***», и готово.

С++ же призван работать со всем на свете, в том числе и с миллионом приложений, написанных на других языках. Значит самый естественный менеджер пакетов для С++ — это slackpkg/apt-get/PackageKit.

[@TargetSan]

Мой личный опыт показывает, что это все окружающие призваны работать с С++ через C ABI. С++ не стыкуется сам по себе ни с кем кроме С и С++. Все остальные делают C-compatible FFI. А пакетный менеджер не родился КМК из-за того, что производителей компиляторов было несколько. И они в начале развития С++ не очень хорошо дружили друг с другом. Посмотрите хотя бы на «зоопарк» систем сборки. Отсюда, кстати, и отсутствие какого-то единого соглашения на структуру исходников для каждого «компонента». Другие языки появлялись усилиями какой-то одной компании или группы энтузиастов, и только потом могли появляться «форки». Либо просто выходил порт референсного компилятора/рантайма.

[@potan]

Как раз в других языках пакетные менеджеры часто устанавливают библиотеки и тулы на C/C++, питоне, даже фортране (в R таких зависимостей очень много). Бывает совсем экзотика, программа на Haskell устанавливяемые через npm.

[@JagaJaga]

Официальный NixOS контрибьютор здесь :) (https://github.com/jagajaga)
Если интересуют ответы на вопросы — задавайте, постараюсь помочь.

[@snizovtsev]

1. NixOS самостоятельна. По сути это PM + декларативная система конфигурации (с ней я не разбирался).
2. Да, там все компоненты кроме ядра свои устанавливаются. Даже на MacOS работает (правда Qt не поддерживается).

[@JagaJaga]

1. Там все просто :) Тоже функции. Плюс дает, имхо, более простой и гибкий вариант конфигурации системы.

[@prefrontalCortex]

А скажите, nixlang базируется на каком-то уже существующем языке? На ML-семейство больно уж похож.

[@JagaJaga]

Нет, он тоже с нуля написан. Это была магисторская работа его автора, вроде.

[@mbait]

Мельком глянул исходники C++ — ночной кошмар программиста. Весь проект в целом — NIH-синдром в терминальной стадии. Про NixOS пока непонятно.

[@Camel]

Говоря про Nix нельзя не упомнять Guix — то же самое, только использует Guile (диалект лиспа, конкретно Scheme) вместо специфичного nixlang.

[@wibotwi]

Могу ли я его локально поставить? Т.е. не имя рут доступа, просто в пользовательскую папку и при этом полноценно использовать?

[@JagaJaga]

Нет, потому что используется папка /nix. Для ее создания нужны root права.

[@Camel]

Нет, потому что можно поставить в $HOME, и бинарники хранить в хоуме же.

И таки мне больше нравится Guix.

[@gregorybednov]

не прошло и 10 лет, как могу сказать: есть nix-user-chroot (https://github.com/nix-community/nix-user-chroot), там такое можно

однако, оно не работает с проектами, собранными под buildFHS (есть такой инструмент в Nix, для обёртывания программ, требующих соответствия FHS) - поэтому да, запустить наиболее тяжелые приложения прямо из никса (например, VSCode) без рутового никса, судя по всему, не выйдет

но что касается инструментов сборки, оно получилось

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

[@VersusVoid]

Если вам потребуется собрать 32-битный пакет под 64-битной системе, можно сделать такой финт ушами:

myProject_i686 = pkgs.pkgsi686Linux.stdenv.mkDerivation {
        name = "myProject-i686-0.0.1";

        buildInputs = [
            pkgs.gcc_multi
            pkgs.glibc_multi
            pkgs.python2
            pkgs.pkgconfig

            pkgs.pkgsi686Linux.boost155
            pkgs.pkgsi686Linux.openssl
            pkgs.pkgsi686Linux.curl
            pkgs.pkgsi686Linux.opencv
        ];
    };