From e39a73cc55bf6fb9559d9d51e1959a5340c2510b Mon Sep 17 00:00:00 2001
From: John Ericson <John.Ericson@Obsidian.Systems>
Date: Sun, 23 Sep 2018 13:18:38 -0400
Subject: [PATCH] doc: Don't mention top-level `{build, host, target}Platform`

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.
---
 doc/cross-compilation.xml | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/doc/cross-compilation.xml b/doc/cross-compilation.xml
index 3b90596bcc2..c7187d86d1b 100644
--- a/doc/cross-compilation.xml
+++ b/doc/cross-compilation.xml
@@ -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>