From: Paul Eggert Date: Sat, 30 Oct 2021 23:28:25 +0000 (-0700) Subject: maint: modernize README-{hacking,prereq} X-Git-Tag: v9.1~197 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=v9.0-15-gaa31b919c;p=thirdparty%2Fcoreutils.git maint: modernize README-{hacking,prereq} --- diff --git a/README-hacking b/README-hacking index be9ea37662..44cb75b987 100644 --- a/README-hacking +++ b/README-hacking @@ -1,34 +1,45 @@ --*- outline -*- +Building from a Git repository -*- outline -*- 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 contribution guidelines. +If this package has a file HACKING, please also read that file for +more detailed 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 +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. -Note the requirements to build the released archive are much less and -are just the requirements of the standard ./configure && make procedure. +(The requirements to build from a release 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 is also highly recommended, if -Valgrind supports your architecture. See also README-valgrind. +Valgrind supports your architecture. See also README-valgrind +(if present). While building from a just-cloned source tree may require installing a -few prerequisites, later, a plain 'git pull && make' should be sufficient. +few prerequisites, later, a plain 'git pull && make' typically suffices. -* First GIT checkout +* First Git checkout You can get a copy of the source repository like this: - $ git clone git://git.sv.gnu.org/coreutils - $ cd coreutils + $ git clone git://git.sv.gnu.org/ + $ cd -As an optional step, if you already have a copy of the gnulib git +where '' stands for 'coreutils' or whatever other package +you are building. + +To use the most-recent Gnulib (as opposed to the Gnulib version that +the package last synchronized to), do this next: + + $ git submodule foreach git pull origin master + $ git commit -m 'build: update gnulib submodule to latest' gnulib + +As an optional step, if you already have a copy of the Gnulib Git repository, then you can use it as a reference to reduce download time and file system space requirements: @@ -39,20 +50,14 @@ 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: - - $ git submodule foreach git pull origin master - $ git commit -m 'build: update gnulib submodule to latest' gnulib - And there you are! Just - $ ./configure --quiet #[--enable-gcc-warnings] [*] + $ ./configure --quiet #[--disable-gcc-warnings] [*] $ make $ make check At this point, there should be no difference between your local copy, -and the GIT master copy: +and the Git master copy: $ git diff @@ -60,12 +65,15 @@ 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. +[*] By default GCC warnings are enabled when building from Git. +If you get warnings with recent GCC and Glibc with default +configure-time options, please report the warnings to the bug +reporting address of this package instead of to bug-gnulib, +even if the problem seems to originate in a Gnulib-provided file. +If you get warnings with other configurations, you can run +'./configure --disable-gcc-warnings' or 'make WERROR_CFLAGS=' +to build quietly or verbosely, respectively. +----- * Submitting patches diff --git a/README-prereq b/README-prereq index 16684a8b86..176fb21996 100644 --- a/README-prereq +++ b/README-prereq @@ -1,65 +1,41 @@ This gives some notes on obtaining the tools required for development. -I.e., the tools checked for by the bootstrap script and include: - -- Autoconf -- Automake -- Bison -- Gettext -- Git -- Gperf -- Gzip -- Perl -- Rsync -- Tar -- Texinfo - -Note please try to install/build official packages for your system. -If these programs are not available use the following instructions -to build them and install the results into a directory that you will -then use when building this package. - -Even if the official version of a package for your system is too old, -please install it, as it may be required to build the newer versions. -The examples below install into $HOME/coreutils/deps/, so if you are -going to follow these instructions, first ensure that your $PATH is -set correctly by running this command: - - prefix=$HOME/coreutils/deps +These tools can be used by the 'bootstrap' and 'configure' scripts, +as well as by 'make'. They include: + +- Autoconf +- Automake +- Bison +- Gettext +- Git +- Gperf +- Gzip +- Help2man +- M4 +- Make +- Perl +- Tar +- Texinfo +- Wget +- XZ Utils + +It is generally better to use official packages for your system. +If a package is not officially available you can build it from source +and install it into a directory that you can then use to build this +package. If some packages are available but are too old, install the +too-old versions first as they may be needed to build newer versions. + +Here is an example of how to build a program from source. This +example is for Autoconf; a similar approach should work for the other +developer prerequisites. This example assumes Autoconf 2.71; it +should be OK to use a later version of Autoconf, if available. + + prefix=$HOME/prefix # (or wherever else you choose) export PATH=$prefix/bin:$PATH - -* autoconf * - - # Note Autoconf 2.62 or newer is needed to build automake-1.11.2 - # but we specify 2.64 here as that's what coreutils requires. - # Please use the latest stable release version as indicated by git tags. - git clone --depth=1 git://git.sv.gnu.org/autoconf.git - cd autoconf - git pull --tags - git checkout v2.64 - autoreconf -vi - ./configure --prefix=$prefix - make install - -* automake * - - # Note help2man is required to build automake fully - git clone git://git.sv.gnu.org/automake.git - cd automake - git checkout v1.11.2 - ./bootstrap - ./configure --prefix=$prefix - make install - -This package uses XZ utils (successor to LZMA) to create -a compressed distribution tarball. Using this feature of Automake -requires version 1.10a or newer, as well as the xz program itself. - -* xz * - - git clone https://git.tukaani.org/xz.git - cd xz - ./autogen.sh + wget https://ftp.gnu.org/pub/gnu/autoconf/autoconf-2.71.tar.gz + gzip -d