X-Git-Url: http://review.tizen.org/git/?a=blobdiff_plain;f=README-hacking;h=d2c127d6473b46d7cb4c1475608aab451c167f11;hb=cd00fa6ee1299c048ce2bda9274cde289bc70bc3;hp=6a2714ad42cbea19a712a6066274dbc4f8bc9b2d;hpb=2d2255272d28d08b8528a0f1660b0fd831966fab;p=platform%2Fupstream%2Fcoreutils.git

diff --git a/README-hacking b/README-hacking
index 6a2714a..d2c127d 100644
--- a/README-hacking
+++ b/README-hacking
@@ -2,63 +2,101 @@
 
 These notes intend to help people working on the checked-out sources.
 These requirements do not apply when building from a distribution tarball.
+See also HACKING for more detailed coreutils contribution guidelines.
 
 * Requirements
 
 We've opted to keep only the highest-level sources in the GIT repository.
 This eases our maintenance burden, (fewer merges etc.), but imposes more
 requirements on anyone wishing to build from the just-checked-out sources.
-For example, you have to use the latest stable versions of the maintainer
-tools we depend upon, including:
-
-- Automake <http://www.gnu.org/software/automake/>
-- Autoconf <http://www.gnu.org/software/autoconf/>
-- Bison <http://www.gnu.org/software/bison/>
-- Gettext <http://www.gnu.org/software/gettext/>
-- Gzip <http://www.gnu.org/software/gzip/>
-- Tar <http://www.gnu.org/software/tar/>
-- Wget <http://www.gnu.org/software/wget/>
-
-As of this writing, the latest stable version of Gzip is 1.2.4 but we
-suggest using test version 1.3.5 (or later, if one becomes available).
+Note the requirements to build the released archive are much less and
+are just the requirements of the standard ./configure && make procedure.
+Specific development tools and versions will be checked for and listed by
+the bootstrap script.  See README-prereq for specific notes on obtaining
+these prerequisite tools.
 
 Valgrind <http://valgrind.org/> is also highly recommended, if
-Valgrind supports your architecture.
+Valgrind supports your architecture. See also README-valgrind.
 
-Only building the initial full source tree will be a bit painful.
-Later, a plain `git-pull && make' should be sufficient.
+While building from a just-cloned source tree may require installing a
+few prerequisites, later, a plain `git pull && make' should be sufficient.
 
 * First GIT checkout
 
-Obviously, if you are reading these notes, you did manage to check out
-this package from GIT.  The next step is to get other files needed to
-build, which are extracted from other source packages:
+You can get a copy of the source repository like this:
+
+        $ git clone git://git.sv.gnu.org/coreutils
+        $ cd coreutils
+
+As an optional step, if you already have a copy of the gnulib git
+repository on your hard drive, then you can use it as a reference to
+reduce download time and disk space requirements:
+
+        $ export GNULIB_SRCDIR=/path/to/gnulib
+
+The next step is to get and check other files needed to build,
+which are extracted from other source packages:
+
+        $ ./bootstrap
+
+To use the most-recent gnulib (as opposed to the gnulib version that
+the package last synchronized to), do this next:
 
-	$ ./bootstrap
+        $ git submodule foreach git pull origin master
+        $ git commit -m 'build: update gnulib submodule to latest' gnulib
 
 And there you are!  Just
 
-	$ ./configure
-	$ make
-	$ make check
+        $ ./configure --quiet #[--enable-gcc-warnings] [*]
+        $ make
+        $ make check
 
 At this point, there should be no difference between your local copy,
 and the GIT master copy:
 
-	$ git-diff
+        $ git diff
 
 should output no difference.
 
 Enjoy!
 
+[*] The --enable-gcc-warnings option is useful only with glibc
+and with a very recent version of gcc.  You'll probably also have
+to use recent system headers.  If you configure with this option,
+and spot a problem, please be sure to send the report to the bug
+reporting address of this package, and not to that of gnulib, even
+if the problem seems to originate in a gnulib-provided file.
+
+* Submitting patches
+
+If you develop a fix or a new feature, please send it to the
+appropriate bug-reporting address as reported by the --help option of
+each program.  One way to do this is to use vc-dwim
+<http://www.gnu.org/software/vc-dwim/>), as follows.
+
+  Run the command "vc-dwim --help", copy its definition of the
+  "git-changelog-symlink-init" function into your shell, and then run
+  this function at the top-level directory of the package.
+
+  Edit the ChangeLog file that this command creates, creating a
+  properly-formatted entry according to the GNU coding standards
+  <http://www.gnu.org/prep/standards/html_node/Change-Logs.html>.
+
+  Run the command "vc-dwim" and make sure its output looks good.
+
+  Run "vc-dwim --commit".
+
+  Run the command "git format-patch --stdout -1", and email its output
+  in, using the output's subject line.
+
 -----
 
-Copyright (C) 2002-2007 Free Software Foundation, Inc.
+Copyright (C) 2002-2010 Free Software Foundation, Inc.
 
-This program is free software; you can redistribute it and/or modify
+This program is free software: you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2, or (at your option)
-any later version.
+the Free Software Foundation, either version 3 of the License, or
+(at your option) any later version.
 
 This program is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ -66,6 +104,4 @@ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.
 
 You should have received a copy of the GNU General Public License
-along with this program; if not, write to the Free Software
-Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
-02110-1301, USA.
+along with this program.  If not, see <http://www.gnu.org/licenses/>.