boost
パッケージはsplit packageなので、複数の出力があります。この場合
$ nix-instantiate --eval -E '(import <nixpkgs> {}).boost.outputs'
[ "out" "dev" ]
out
出力は、ライブラリを有し、そしてdev
出力はヘッダを有します。 nix-env -i
を使用すると、通常、dev
の出力はユーザー環境にインストールされません。しかし、パッケージが別のパッケージのビルド依存である場合は、内部的に使用されます。
あなたは次のようにインストールされますどのような出力を確認できます。
$ nix-instantiate --eval -E 'builtins.toString (import <nixpkgs> {}).boost.meta.outputsToInstall'
"out"
ドキュメントは、あなたが他の出力をしたい場合は、meta.outputsToInstall
を上書きできることを示しています。
これを行うことで、私の最高の試みがある:
nix-env -i -E \
'_: with import <nixpkgs> {};' \
'let newmeta = (boost.meta // { outputsToInstall = ["out" "dev"]; });' \
'in boost // { meta = newmeta; }'
はあまり面倒なバージョンを聞いて興味がある...
私は本当の答えは、我々がしようとすべきではないということである疑いがあります開発環境をユーザー環境にインストールします。恐らく、開発の依存関係を定義するdefault.nix
ファイルを作成し、それをnix-shell
でインスタンス化する方が良いでしょう。例えば、https://garbas.si/2015/reproducible-development-environments.htmlを参照してください。
ライブラリをインストールするために 'nix-env -i'が使われたことは一度もありません。通常は実行可能ファイルに使われます。ヘッダーが現在の世代のプロファイルにないと言うと、正確にはどういう意味ですか?実行したコマンドを正確に表示して、期待される出力が何で、実際の出力が何であるかを言うことができますか?ヘッダーを期待通りにインストールする別のライブラリの例がありますか? –
固有値、qt5、opencsg、qscintilla .... nix-envのこれらのパッケージで '-i'を使うと、〜/ .nix-profile /内にヘッダのシンボリックリンクが生成されます –