ニックスはC ++が大好き

最近、C ++にはpip、npm、maven、cargoなどの独自のパッケージマネージャーが必要であるという多くの話があります。すべての競合他社には、非標準ライブラリを接続するためのシンプルで標準化されたメカニズムがあります。 C ++では、誰もができる限り行動します：誰かがUbuntu、CentOS、その他のディストリビューション用のパッケージのリストをREADMEに書き込み、誰かがgitサブモジュールとスクリプトを使用してそれらを構築し、誰かがCMake ExternalProjectを使用し、誰かがすべてのソースをコピーします1つの巨大なリポジトリ、誰かがDockerまたはVagrantのイメージを作成します。

この問題を解決するために、スタートアップ-biicodeも作成されましたが、破産し、将来は不明です。代わりにコナンが登場し、競合他社の動物園の動物園、 cget 、ハンター、 cpm 、 qpm 、 cppget 、 pacm 、さらにはgradle for c ++を補完しました。

上記のいずれの方法にも満足できませんでした。 Conanのパッケージを書き始めましたが、多数のハック、未開発のAPI、ガイドラインの欠如、そしてその結果、他の人のパッケージを再利用する可能性が低いことに遭遇しました。そして、私はNixOSのパッケージマネージャーのアイデアが本当に好きだったことを思い出しました。そして、私は考えました-通常のパッケージマネージャーが同じ問題を解決するのであれば、なぜC ++専用のパッケージマネージャーを作成するのですか？パッケージの説明に関しては、十分に柔軟でシンプルであることが必要です。そして、Nixはこの役割にぴったりでした。

それで、Nixが私たちに与えたもの：

1つのコマンドnix-shell

プロジェクト環境を構築する準備を整える機能。
nixpkgs

既製およびサポートパッケージ。
リポジトリーのパッケージから派生パッケージを作成する機能（コードをコピーせずに）。
依存関係のC / C ++ライブラリだけでなく、必要なツール（CMake、GCC）、他のエコシステムのプロジェクト（npm、pip）、サービス（redis）も指定する機能。
コミットする環境をバインドする機能。これは、たとえば、masterブランチがboost 1.55とdevel-1.60を使用できることを意味します。ブランチからブランチに切り替えると、Nixは目的のバージョンの環境を自動的に構成します。これには1秒もかかりません（アセンブリが既にキャッシュにある場合）。
非侵入性-プロジェクトはNixに依存せず、その使用は誰にとっても個人的な問題です。 cmakeのすべての正しいオプションを指定して、すべての依存関係を手動で（またはお気に入りのパッケージマネージャーによって）収集できます。

ニックスとは

Nixは、パッケージマネージャーのニーズに合わせて調整された関数型プログラミング言語です（Haskellコミュニティで人気を博したのは驚くことではありません）。パッケージアセンブリは、Nixでの関数計算です。関数型プログラミング言語の場合と同様に、同じ引数を使用して関数を繰り返し呼び出すと、同じ結果が生成されます（バイナリパッケージ）。これは、パッケージをキャッシュできることを意味します。これは、Nixが行うことです。すべてのアセンブリは、 /nix/store/$HASH-$PKGNAME

格納されます。さらに、ネットワーク上の他の誰かが同じハッシュを持つパッケージを持っているかどうかを確認できます。持っている場合は、その人からバイナリパッケージをダウンロードします。

したがって、Nixの「パッケージ」（ここでは派生）は関数であり、「依存関係」はこの関数の引数です。リポジトリ（ NixPkgs

）とは何ですか？これも引数を持たない関数であり、多くのパッケージを返します。リポジトリを使用するには、すべての7344パッケージを収集する必要がありますか？いや！ Nixは遅延言語です。つまり、明らかに必要になるまで何も計算されません。また、ユーティリティを使用してパッケージを「必要」にすることができます。

最小限の環境

したがって、Nixを使用する前に、インストールする必要があります。これを行うには、Linuxディストリビューション全体（NixOS）を使用するか、お気に入りのOSに個別にパッケージマネージャーをインストールします（LinuxおよびMacOSがサポートされています）。すべてのNixの公開は、 /nix

ディレクトリとホームディレクトリ内のファイル（ ~/.nix-channel

、 .nix-defexpr

、 .nix-profile

）に.nix-profile

。

~/.nix-profile

は、ユーザーが要求したパッケージへのシンボリックリンクを保存します。ユーザー用ではなく、プロジェクト用に環境を構成する必要があります。これを行うには、 nix-shell

ユーティリティを使用します。入力で指定されたNix式を実行し、bashシェルを起動します。bashシェルでは、結果（およびそれのみ）を使用できます。私たちはチェックします：

 bash-3.2$ nix-shell -p stdenv [nix-shell:~]$

ここでは、（- -p

） stdenv

パッケージを式として使用します。 stdenv

は、コンパイラ、make、およびその他の重要な要素を含む最小限の環境です。

パッケージ構築環境

引数なしでnix-shell

を実行すると、式はdefault.nix

ファイルから読み取られます。作成する：

 { pkgs ? import <nixpkgs> {} }: let stdenv = pkgs.stdenv; in rec { myProject = stdenv.mkDerivation { name = "my-project"; }; }

ここでは、入力としてリポジトリーを受け入れ（パラメーターが指定されていない場合は、標準のnixpkgs

インポートする）、プロジェクト環境の「パッケージ」を返すnixpkgs

。 NixOSリポジトリから新しいCMake、Boost、Google Testを追加します。

 # ... myProject = stdenv.mkDerivation { name = "my-project"; nativeBuildInputs = [ pkgs.cmake ]; buildInputs = [ pkgs.boost pkgs.gtest ]; };

ここで、buildInputsはビルドに必要な依存関係です。他にnativeBuildInputsがあるのはなぜですか？問題は、Nixがクロスコンパイルをサポートしていることです。ここで、buildInputsパッケージはターゲットツールチェーンによってビルドされ、nativeBuildInputsは通常のホストツールチェーンを使用してビルドされる必要があると言います。また、 propagatedBuildInputs

もあります。パッケージのすべてのユーザーに依存関係が追加されます。

これで、次回nix-shell

を呼び出すと、Nixは必要なバイナリパッケージをダウンロードし、環境変数を設定して、CMakeなどの標準ツールを使用してライブラリが見つかるようにします。

 find_package(Boost 1.60 REQUIRED COMPONENTS system thread) find_path(GTEST_INCLUDE_DIRS NAMES gtest/gtest.h PATH_SUFFIXES gtest)

開発者はcmake . && make

のみを実行cmake . && make

cmake . && make

、 nix-shell

に入るときに彼に通知しnix-shell

：

  myProject = stdenv.mkDerivation { # ... shellHook = ['' echo Welcome to myproject! echo Run \'mkdir build && cd build && cmake .. && make -j\' to build it. '']; };

`nixpkgs`

ない依存関係を構築し`nixpkgs`

次に、プロジェクトにcppformatを追加します。まず、 nixpkgs

で探します：

 $ nix-env -qaP | grep cppformat $ nix-env -qaP | grep cpp-format

空です。独自の式を作成する必要があります。幸いなことに、これはわずか10行です。それらを「let」に追加します。

 # ... let stdenv = pkgs.stdenv; fetchurl = pkgs.fetchurl; cppformat = stdenv.mkDerivation rec { version = "2.1.0"; name = "cppformat-${version}"; src = fetchurl { url = "https://github.com/cppformat/cppformat/archive/${version}.tar.gz"; sha256 = "0h8rydgwbm5gwwblx7jzpb43a9ap0dk2d9dbrswnbfmw50v5s7an"; }; buildInputs = [ pkgs.cmake ]; enableParallelBuilding = true; }; in rec { # ... buildInputs = [ # ... cppformat ]; # ...

次に、 nix-shell

次に実行するときに、Nixはcppformatソースをダウンロードし、cmakeを使用してコンパイルします（プロジェクトではcmakeを使用しているため、標準の「 ./configure && make install

」の代わりに「 cmake . && make install

/nix/store

ビルドします。他のほとんどのパッケージマネージャーのユーティリティとは異なり、次の点に注意してください。

アセンブリが失敗した場合、ソースは再びポンプアウトされません。
式を変更すると、パッケージが再コンパイルされます。後で式をロールバックすることにした場合、ファイルの変更日が変更されても（ブランチ/コミットを変更する場合に便利）、キャッシュの古いパッケージが自動的に使用されます。

リポジトリからパッケージを変更します

リポジトリにパッケージが存在することもありますが、希望どおりにビルドされていません。特定のバージョンを収集し、パッチを適用し、特定のフラグを使用する必要があります。 Nixを使用すると、リポジトリからコードをコピーアンドペーストすることなくこれを行うことができます。

  cpp-netlib = pkgs.cpp-netlib.overrideDerivation(oldAttrs: { postPatch = '' substituteInPlace CMakeLists.txt \ --replace "CPPNETLIB_VERSION_PATCH 1" "CPPNETLIB_VERSION_PATCH 3" ''; cmakeFlags = oldAttrs.cmakeFlags ++ [ "-DCMAKE_CXX_STANDARD=11" ]; src = fetchFromGitHub { owner = "cpp-netlib"; repo = "cpp-netlib"; rev = "9bcbde758952813bf87c2ff6cc16679509a40e06"; # 0.11-devel sha256 = "0abcb2x0wc992s5j99bjc01al49ax4jw7m9d0522nkd11nzmiacy"; }; });

リポジトリ内のパッケージを変更します

リポジトリの元のXに基づいて派生パッケージX 'を構築し、自宅で使用できます。さらに、リポジトリ内の一部のパッケージYがXに依存している場合、引き続き古いバージョンが使用されます。しかし、リポジトリ内のパッケージを変更する必要がある場合、つまり他の100,500個のパッケージで使用されるように？この場合、Nixにはツールがあります。標準のGCC 4.9の代わりにnixpkgs

を使用して、nixpkgsからブーストを再構築します。

 { nixpkgs ? import <nixpkgs> {} }: let overrideCC = nixpkgs.overrideCC; stdenv = if ! nixpkgs.stdenv.isLinux then nixpkgs.stdenv else overrideCC nixpkgs.stdenv nixpkgs.gcc5; pkgs = nixpkgs.overridePackages (self: super: { boost = super.boost.override { stdenv = stdenv; }; });

ここで、引数名をnixpkgs

からnixpkgs

に変更し、必要にnixpkgs

てブーストが構築される派生的なnixpkgs

リポジトリを作成します。これで、ブーストに依存する他のすべてのパッケージを再構築して、アセンブリを使用する必要があります。もちろん、式の中で使用されるパッケージのみが（再帰的に）再構築されます。結局、Nixは怠け者です。

サードパーティのパッケージマネージャーおよびプラットフォームとの統合

ここでもすべてが簡単です-Nixは.NET、Emacs、Go、Haskell、Lua、Node、Perl、PHP、Python、Rustのパッケージのビルドをサポートしています。それらの一部については、Nixがネイティブパッケージマネージャーから直接パッケージを使用できるという統合があります。

 nativeBuildInputs = [ pkgs.cmake pkgs.pkgconfig nodePackages.uglify-js ];

NixをYouCompleteMeに統合する

YouCompleteMeは、おそらくIDEの一部ではない最も人気のあるC ++コード補完エンジンです。彼はVimを辞めましたが、すでにAtomや他のエディター向けの移植版があります。以前の開発者がシステム用に個別に構成する必要があった場合、今では普遍的に行うことができます。

 def ExportFromNix(): from subprocess import Popen, PIPE import shlex cmd = "nix-shell -Q --pure --readonly-mode --run 'echo $NIX_CFLAGS_COMPILE'"; proc = Popen(cmd, shell=True, stdout=PIPE) out = proc.stdout.read().decode("utf-8") return shlex.split(out) flags += ExportFromNix()

おわりに

Nixは、機能的プログラミングの原理に基づいて構築され、すべてのパッケージマネージャーであると主張する、柔軟で便利でシンプルなパッケージマネージャーです。特に、C / C ++プログラマーにとっては便利です。この言語では空のニッチを埋めることができます。これを使用すると、同僚を苦しめたり嫌いにしたりすることなく、プロジェクトにライブラリをパッチして追加できます。また、チームに到着した新参者は、プロジェクトの組み立てに最初の就業日を費やすことはありません。

C ++の依存関係マネージャーとしてのNix