From 10d2ef04cf658de8cfded4123b3b99e589591fbe Mon Sep 17 00:00:00 2001
From: P. J. McDermott <pjm@nac.net>
Date: Thu, 15 Nov 2012 21:09:47 -0500
Subject: Move README to README.source.

It doesn't need to be installed with the binary packages.
---
(limited to 'README')

diff --git a/README b/README
deleted file mode 100644
index daf007e..0000000
--- a/README
+++ /dev/null
@@ -1,53 +0,0 @@
-Binutils Package
-================
-
-Building the Binutils Package
------------------------------
-
-If you want to temporarily change the targets for which Binutils is built, run
-the following commands before building:
-
-    $ ./config clean
-    $ PKG_TARGETS='list of architectures' ./config
-
-The default targets are listed in the `targets.in` file.
-
-To configure Binutils to be built for all default targets, run the following
-commands before building:
-
-    $ ./config clean
-    $ ./config
-
-Binutils Build System Mangling
-------------------------------
-
-[See `patches/01_pass-some-dirs-to-child-makes.patch` for some background
-information.]
-
-An alternative to `patches/01_pass-some-dirs-to-child-makes.patch` is to run
-make in each subdirectory ourselves instead of letting the top-level makefile do
-it for us.  This way, we can leave the build system untouched and directly give
-each child make process the required macro settings.
-
-There are ten subdirectories in which we would need to run make (though of
-course we don't currently enable some of them, e.g. `gold`):
-
-  * `bfd`
-  * `opcodes`
-  * `binutils`
-  * `etc`
-  * `gas`
-  * `gold`
-  * `gprof`
-  * `intl`
-  * `ld`
-  * `libiberty`
-
-The disadvantage to this is a higher maintenance cost: we need to keep track of
-the subdirectories in which we need to run make.  We need to watch out for
-changes to the dependencies of `install-host` and `install-target` in Binutils's
-Makefile.in (unlikely) and changes in the features (e.g. gold) we enable
-(likely).
-
-The trivial patch (which adds just three lines) should apply cleanly across
-Binutils releases, so it seems best to just stick with that.
--
cgit v0.9.1