Update documentation with BUILDROOT_USE_XWINDOWS, & linux cleanup

diff --git a/docs/buildroot.html b/docs/buildroot.html
index b282a19a68c45d56eeb2e76cda27d4261b667545..abd4d265a5ae958b3559d6935aefd102f2b5ba79 100644 (file)
--- a/docs/buildroot.html
+++ b/docs/buildroot.html
@@ -247,6 +247,9 @@
     <li>HOSTCC</li>
     <li>UCLIBC_CONFIG_FILE=&lt;path/to/.config&gt;</li>
     <li>BUSYBOX_CONFIG_FILE=&lt;path/to/.config&gt;</li>
+    <li>BUILDROOT_DL_DIR</li>
+    <li>BUILDROOT_LOCAL</li>
+    <li>BUILDROOT_USE_XWINDOWS</li>
     </ul>
 
     <p>An example that uses config files located in the toplevel directory and
@@ -635,52 +638,22 @@ $ make me&lt;TAB&gt;
     conflicts, but will use unique build directories, where the user
     can configure the build. </p>
 
-    <p><b>THINGS TO DO</b></p>
-
+    <h2><a name="Linux" id="Linux"></a>Linux</h2>
     <ol>
 
-    <li>Linux</li>
-
-    <p>The current Linux implementation is flawed. It only works
-    if the user chooses to use one of the few kernels selected
-    as base for the kernel-headers. While the Makefile seems to have
-    hooks, allowing the developer to specify whatever version he/she
-    wants in the target/device/*/* Makefiles, the build will fail
-    if another kernel version is choosen.</p>
-
-    <p>The reason for this is that the kernel patches are not
-    applied by the <code>&quot;target/linux/linux.mk&quot;</code>
-    build script fragment. They are only applied by the
-    <code>&quot;toolchain/kernel-headers/*.makefile&quot;</code>
-    build script fragments</p>
-
-    <p>If the kernel-header version and the linux version differs,
-    there will be two <code>&quot;linux-2.6.X.Y&quot;</code>
-    directories in
-    <code>&quot;build_&lt;ARCH&gt;/&lt;&gt;&quot;</code>,
-    each with its own set of patches. </p>
-
-    <p>The solution in the works, is to move the build of Linux to
-    <code>&quot;project_build_&lt;ARCH&gt;/&lt;project name&gt;/linux-2.6.X.Y&quot;</code> combined with method to configure
-     which patches can be applied. Possibly, the linux source tree
-     used to generate the kernel headers will be moved to the
-     <code>&quot;toolchain_build_&lt;ARCH&gt;&quot;</code>
-     directory
-      </p>
-
-     <p>The user will be able to select from three different
-     Linux strategies:
+
+     <p>The user can select from three different Linux strategies:
 
      <ul>
-     <li>Conservative Strategy: Only use version ssupported by the kernel headers</li>
-     <li>Stable Linux Strategy: Allow any 2.6.X.Y combination.
+     <li>Legacy: Only use version supported by the kernel headers</li>
+     <li>Advanced: Allow any 2.6.X.Y combination.
        (Minimum 2.6.19)</li>
      <li>Power-User Strategy: Allow
      <code>&quot;-git&quot;</code>, or
      <code>&quot;-mm&quot;</code>, or user downloadable kernels</li>
      </ul>
 
-     <p>The current kernel patches can be configured to be applied to the
+     <p>The current kernel patches can be applied to the
      linux source tree even if the version differs from the
      kernel header version. </p>
 
@@ -690,7 +663,7 @@ $ make me&lt;TAB&gt;
      proprietary kernel-patch or decide to not apply the kernel
      patches</p>
 
-     <p>Other optional patches will be <u>board specific</u> or
+     <p>There is also support for <u>board specific</u> and
      <u>architecture specific</u> patches. </p>
 
      <p>There will also be a way for the user to supply absolute
@@ -701,9 +674,27 @@ $ make me&lt;TAB&gt;
 
      <p>Maybe, there will also be a possibility to supply an
      <code>&quot;URL&quot;</code> to a patch available on Internet. </p>
+<pre>
+export BUILDROOT_USE_XWINDOWS &lt;&gt;
+</pre>
+
+     <p>
+       If there is no linux config file available,
+       buildroot starts the linux configuration system, which
+       defaults to "make menuconfig". There is a menuoption
+       allowing you to use the less archaic "make  xconfig"
+       You can override any .config setting by defining
+       the BUILDROOT_USE_XWINDOWS environment variable.
+     </p>
 
-     <li>Configurable packages</li>
 
+
+    </ol>
+
+    <h2><a name="Todo" id="Todo"></a>Todo</h2>
+    <ol>
+
+     <li>Configurable packages</li>
      <p>Many packages can, on top of the simple
      &quot;enable/disable build&quot;,
      be further configured using Kconfig.