JakeHillion/nixpkgs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

doc: Don't mention top-level {build, host, target}Platform

Browse Source 
For technical reasons, we cannot easily add a warning to top-level
definitions, so 2a6e4ae49a891adc7c0562fda08b17d60beb1b4f and
e51f736076548459f36a1250de4bf6867f880b66 reverted the deprecation. But
we can still remove mention of the would-be deprecated definitions to
steer people towards using the preferred alternatives.
This commit is contained in:
John Ericson 2018-09-23 13:18:38 -04:00
parent 359d00f8b0
commit e39a73cc55
1 changed files with 3 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
doc/cross-compilation.xml
View File

@ -47,13 +47,9 @@
<para>
In Nixpkgs, these three platforms are defined as attribute sets under the
names <literal>buildPlatform</literal>, <literal>hostPlatform</literal>,
and <literal>targetPlatform</literal>. All three are always defined as
attributes in the standard environment, and at the top level. That means
one can get at them just like a dependency in a function that is imported
with <literal>callPackage</literal>:
<programlisting>{ stdenv, buildPlatform, hostPlatform, fooDep, barDep, .. }: ...buildPlatform...</programlisting>
, or just off <varname>stdenv</varname>:
names <literal>buildPlatform</literal>, <literal>hostPlatform</literal>, and
<literal>targetPlatform</literal>. They are always defined as attributes in
the standard environment. That means one can access them like:
<programlisting>{ stdenv, fooDep, barDep, .. }: ...stdenv.buildPlatform...</programlisting>
.
</para>