HACKING

   1 ================================================================
   2 = This file
   3
   4 * This file attempts to describe the rules to use when hacking
   5   automake.
   6
   7 * Don't put this file into the distribution.  Don't mention it in the
   8   ChangeLog.
   9
  10 ================================================================
  11 = Administrivia
  12
  13 * If you incorporate a change from somebody on the net:
  14   First, if it is a large change, you must make sure they have signed the
  15   appropriate paperwork.
  16   Second, be sure to add their name and email address to THANKS
  17
  18 * If a change fixes a test, mention the test in the ChangeLog entry.
  19
  20 * If somebody reports a new bug, mention his name in the ChangeLog entry
  21   and in the test case you write.  Put him into THANKS.
  22
  23 * When documenting a non-trivial idiom or example in the manual, be
  24   sure to add a test case for it, and to reference such test case from
  25   a proper Texinfo comment.
  26
  27 * The correct response to most actual bugs is to write a new test case
  28   which demonstrates the bug.  Then fix the bug, re-run the test suite,
  29   and check everything in.
  30
  31 * Some files in the automake package are not owned by automake.  These
  32   files should never be edited here.  These files are
  33       COPYING (from FSF),
  34       INSTALL (autoconf-patches@gnu.org),
  35       config.guess, config.sub (config-patches@gnu.org),
  36       texinfo.tex (bug-texinfo@gnu.org),
  37   Most of them are updated before release with `make fetch'.
  38
  39 * Changes other than bug fixes must be mentioned in NEWS.  Important
  40   bug fixes should be mentioned in NEWS, too.
  41
  42 ================================================================
  43 = Naming
  44
  45 * We've adopted the convention that internal AC_SUBSTs should be
  46   named with a leading `am__', and internally generated targets
  47   should be named with a leading `am--'.  This convention, although
  48   in place from at least February 2001, isn't yet universally used.
  49   But all new code should use it.
  50
  51   We used to use `_am_' as the prefix for an internal AC_SUBST.
  52   However, it turns out that NEWS-OS 4.2R complains if a Makefile
  53   variable begins with `_'.  Yay for them.  I changed the target
  54   naming convention just to be safe.
  55
  56 ================================================================
  57 = Editing `.am' files
  58
  59 * Always use $(...) and not ${...}
  60
  61 * Use `:', not `true'.  Use `exit 1', not `false'.
  62
  63 * Use `##' comments liberally.  Comment anything even remotely
  64   unusual.
  65
  66 * Never use basename or dirname.  Instead use sed.
  67
  68 * Do not use `cd' within back-quotes, use `$(am__cd)' instead.
  69   Otherwise the directory name may be printed, depending on CDPATH.
  70   More generally, do not ever use plain `cd' together with a relative
  71   directory that does not start with a dot, or you might end up in one
  72   computed with CDPATH.
  73
  74 * For install and uninstall rules, if a loop is required, it should be
  75   silent.  Then the body of the loop itself should print each
  76   "important" command it runs.  The printed commands should be preceded
  77   by a single space.
  78
  79 ================================================================
  80 = Editing automake.in and aclocal.in
  81
  82 * Indent using GNU style.  For historical reasons, the perl code
  83   contains portions indented using Larry Wall's style (perl-mode's
  84   default), and other portions using the GNU style (cperl-mode's
  85   default).  Write new code using GNU style.
  86
  87 * Don't use & for function calls, unless required.
  88   The use of & prevents prototypes from being checked.
  89   Just as above, don't change massively all the code to strip the
  90   &, just convert the old code as you work on it, and write new
  91   code without.
  92
  93 ================================================================
  94 = Working with git
  95
  96 * To regenerate dependent files created by aclocal and automake,
  97   use the `bootstrap' script.  It uses the code from the source
  98   tree, so the resulting files (aclocal.m4 and Makefile.in) should
  99   be the same as you would get if you install this version of
 100   automake and use it to generate those files.  Be sure to have the
 101   latest stable version of Autoconf installed.  If such version is
 102   not installed as "autoconf", pass it explicitly (along with the
 103   accompanying "autom4te") when calling `bootstrap' and `configure'.
 104   For example:
 105     $ AUTOCONF=autoconf2.68 AUTOM4TE=autom4te2.68 ./bootstrap
 106     $ ./configure AUTOCONF=autoconf2.68 AUTOM4TE=autom4te2.68
 107
 108 * Dependent files aclocal.m4, configure and Makefile.in in all
 109   directories should be up to date in the git repository, so that
 110   the changes in them can be easily noticed and analyzed.
 111
 112 * The git tree currently carries a number of branches: master for the
 113   current development, and release branches named branch-X.Y.  The maint
 114   branch serves as common ground for both master and the active release
 115   branches.  Changes intended for both should be applied to maint, which
 116   should then be merged to release branches and master, of course after
 117   suitable testing.  It is advisable to merge only after a set of related
 118   commits have been applied.
 119
 120 * Example work flow for patches to maint:
 121
 122   # 1. Checkout the "maint" branch:
 123   git checkout maint
 124
 125   # 2. Apply the patch(es) with "git am" (or create them with $EDITOR):
 126   git am -3 0*.patch
 127   # 2a. Run required tests, if any ...
 128
 129   # 3. Merge maint into branch-1.11:
 130   git checkout branch-1.11
 131   git merge maint
 132   # 3a. Run required tests, if any ...
 133
 134   # 4. Redo steps 3 and 3a for master:
 135   git checkout master
 136   git merge maint
 137   # testing ...
 138
 139   # 5. Push the maint and master branches:
 140   git push --dry-run origin maint branch-1.11 master
 141   # if all seems ok, then actually push:
 142   git push origin maint branch-1.11 master
 143
 144 * When fixing a bug (especially a long-standing one), it may be useful
 145   to commit the fix to a new temporary branch based off the commit that
 146   introduced the bug.  Then this "bugfix branch" can be merged into all
 147   the active branches descending from the buggy commit.  This offers a
 148   simple way to fix the bug consistently and effectively.
 149
 150 * When referring to older commits, use 'git describe' output as pointer.
 151
 152 * There may be a number of longer-lived feature branches for new developments.
 153   They should be based off of a common ancestor of all active branches to
 154   which the feature should be merged later.  The next branch may serve as
 155   common ground for feature merging and testing, should they not be ready
 156   for master yet.
 157
 158 * For merges from branches other than maint, prefer 'git merge --log' over
 159   plain 'git merge', so that a later 'git log' gives an indication of which
 160   actual patches were merged even when they don't appear early in the list.
 161
 162 * master and release branches should not be rewound, i.e., should always
 163   fast-forward, except maybe for privacy issues.  The maint branch should not
 164   be rewound except maybe after retiring a release branch or a new stable
 165   release.  For next, and for feature branches, the announcement for the
 166   branch should document rewinding policy.
 167
 168 * In order for rebasing and merging of ChangeLog entries to work seamlessly,
 169   install and configure git-merge-changelog, currently available as gnulib
 170   module.
 171
 172 ================================================================
 173 = Test suite
 174
 175 * Use "make check" and "make maintainer-check" liberally.
 176
 177 * Make sure each test file is executable.
 178
 179 * Use `keep_testdirs=yes' to keep test directories for successful
 180   tests also.
 181
 182 * Use perl coverage information to ensure your new code is thoroughly
 183   tested by your new tests.
 184
 185 * See file `tests/README' for more information.
 186
 187 ================================================================
 188 = Release procedure
 189
 190 * Fetch new versions of the files that are maintained by the FSF.
 191   Commit.  Unfortunately you need an FSF account to do this.
 192   (You can also use `make fetch', but that is still woefully incomplete.)
 193
 194 * Update NEWS.  For an alpha release, update README-alpha.
 195
 196 * Update the version number in configure.ac.
 197   (The idea is that every other alpha number will be a net release.
 198   The repository will always have its own "odd" number so we can easily
 199   distinguish net and repo versions.)
 200
 201 * Update ChangeLog.
 202
 203 * Run ./bootstrap, ./configure, make.
 204
 205 * Run `make release-stats' if release statistics in doc/automake.texi
 206   have not been updated yet.
 207
 208 * Run `make git-release'.
 209   This will run distcheck to create the tarballs, commit the last
 210   NEWS/configure.ac/ChangeLog changes, tag the repository, sign
 211   the tarballs, and upload them.
 212   Use `make GNUPLOADFLAGS="--user key" git-release' to sign with
 213   a non-default key.
 214
 215 * Update version number in configure.ac to next alpha number.
 216   Re-run ./bootstrap and commit.
 217
 218 * Don't forget to `git push' your changes so they appear in the public
 219   git tree.
 220
 221 * Update the web pages at sources.redhat.com:
 222   - bump version in index.rst,
 223   - add entry to news.rst,
 224   - run `make' to update .html files,
 225   - create manuals:
 226       cd doc
 227       make pdf
 228       make html MAKEINFOFLAGS=--no-split
 229   - copy automake.html and automake.pdf to web cvs,
 230   - add ChangeLog entry and commit.
 231
 232 * Update the manuals at www.gnu.org:
 233   - Generate manuals:
 234     cd doc
 235     wget "http://savannah.gnu.org/cgi-bin/viewcvs/~checkout~/texinfo/texinfo/util/gendocs.sh"
 236     wget "http://savannah.gnu.org/cgi-bin/viewcvs/~checkout~/texinfo/texinfo/util/gendocs_template"
 237     sh ./gendocs.sh --email bug-automake@gnu.org automake "GNU Automake"
 238   - copy manuals recursively to web cvs,
 239   - commit.
 240   - Check for link errors, fix them, recheck until convergence:
 241     <http://validator.w3.org/checklink>
 242
 243 * Send announcement at least to autotools-announce@gnu.org, and
 244   automake@gnu.org.  If not an alpha, announcement must also go to
 245   info-gnu@gnu.org.  Copy this announcement into the NEWS feed at
 246   <https://savannah.gnu.org/projects/automake>.
 247
 248 -----
 249
 250 Copyright (C) 2003, 2007, 2008, 2010, 2011 Free Software Foundation,
 251 Inc.
 252
 253 This program is free software; you can redistribute it and/or modify
 254 it under the terms of the GNU General Public License as published by
 255 the Free Software Foundation; either version 2, or (at your option)
 256 any later version.
 257
 258 This program is distributed in the hope that it will be useful,
 259 but WITHOUT ANY WARRANTY; without even the implied warranty of
 260 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 261 GNU General Public License for more details.
 262
 263 You should have received a copy of the GNU General Public License
 264 along with this program.  If not, see <http://www.gnu.org/licenses/>.
 265
 266 Local Variables:
 267 mode: text
 268 End: