=============
* When writing tests, make sure the link invocation (first argument to
- AT_CHECK) is on a single line so that 'testsuite -x' displays the
- whole thing.
+ AT_CHECK) is on a single line so that `testsuite -x' displays the
+ whole thing. You can use m4_do or `[... ]dnl' to wrap long lines.
* Use
+ make -k check
+ liberally, on as many platforms as you can. Use as many compilers and
+ linkers you can. To run old and new testsuites separately, use
make check TESTSUITEFLAGS=-V
make check-local
- liberally, on as many platforms as you can. Use as many compilers and
- linkers you can.
* The new Autotest testsuite uses keywords to denote test features:
autoconf needs Autoconf
* Preferably the next part should be a description of the overall
purpose of the change, separated from the header by a blank line,
indented by 1 tab, and filled at column 72. The last character of the
- description should be a colon, :.
+ description should be a period. Ideally, this description fits on one
+ line, or begins with a one-line summary.
* Changes to each file come next. Each new file starts on a new line,
indented by 1 tab and starting with an asterisk and a space. Multiple
Peter O'Gorman <peter@pogma.com>
This is the overall description of the purpose of this change
- and any useful background for a model ChangeLog entry:
+ and any useful background for a model ChangeLog entry.
* HACKING: Updated copyright. This isn't attached to a
particular section of the file, so it comes first.
* NEWS: Updated.
Reported by Bob Friesenhahn <bfriesen@simple.dallas.tx.us>.
+
+6. Using git
+============
+
+* Preferably, let the git commit message mirror the ChangeLog entry,
+ without the leading TABs. Use --author for the (first, main) author
+ of patches from others, sign patches you have reviewed. If the
+ ChangeLog entry is longer than a line, use a one line summary, then an
+ empty line, then the rest of the log entry; this makes for nice output
+ of `git log'.
+
* You may find it useful to install the git-merge-changelog merge driver:
- http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c
+ <http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c>
+
+* Do not ever rewind the public master branch nor any public release
+ branch on savannah, neither any release tags once they have been
+ published. Other branches and tags may have different rules.
+
+* Avoid merge commits on the master branch of the public git repository.
+ For unpublished changes in your development tree, it's easiest to
+ rebase against the current master before applying them, this preserves
+ a linear history.
+
-6. Editing `.am' Files
+7. Editing `.am' Files
======================
* Always use $(...) and not ${...}
and will be fixed in the `libtoolize --ltdl --(non)recursive' stage.
-7. Editing `.m4sh' Files
+8. Editing `.m4sh' Files
========================
* Use shell functions, but be careful not to assume local scope for
]])
-8. Editing `.m4' Files
+9. Editing `.m4' Files
======================
* Be careful with both `echo' and `$ECHO'. As the latter may be one of
be updated in all newer versions.
-9. Abstraction layers in libltdl
-================================
+10. Abstraction layers in libltdl
+=================================
* The libltdl API uses a layered approach to differentiate internal and
external interfaces, among other things. To keep the abstraction
loading: preopen.c, dlopen.c etc.
-10. Licensing Rules
+11. Licensing Rules
===================
GNU Libtool uses 3 different licenses for various of the files distributed
along with some notes on when each is appropriate. Appropriate commenting
(shell, C etc) and decoration (m4sh etc) assumed throughout.
-10.1. Notice preservation
+11.1. Notice preservation
Autoconf macros and files used to generate them need this license:
-10.2. GPL
+11.2. GPL
Everything else in the distribution has the following license text
unless there is good reason to use one of the other license texts
-10.3. GPL with Libtool exception clause
+11.3. GPL with Libtool exception clause
At the moment only `libltdl/README' needs the exception clause to
allow projects that distribute a copy of the libltdl sources to also
-10.4. GPL with Cvs-utils exception clause
+11.4. GPL with Cvs-utils exception clause
GNU Libtool imports some m4sh infrastructure from the GNU Cvs-utils
project, namely `getopt.m4sh' and `general.m4sh'. Those files use
-10.5. GPL with self extracting version
+11.5. GPL with self extracting version
Some of the sources built atop Cvs-utils' m4sh framework use
getopt.m4sh:func_version() to extract their --version output from
-10.6. GPL with self extracting version and Libtool exception clause
+11.6. GPL with self extracting version and Libtool exception clause
Although the libtool script is generated from `ltmain.m4sh' according
to the rules in the preceding subsection, it also needs the Libtool
-10.7. LGPL with Libtool exception clause
+11.7. LGPL with Libtool exception clause
Finally, not only is Libltdl is LGPLed, but it is routinely
redistributed inside projects that use it, so its sources need to use
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-11. Release Procedure
+12. Release Procedure
=====================
* If you are a libtool maintainer, but have not yet registered your
* Make sure your locale is sane, e.g. by exporting LC_ALL=C.
* Double check that serial number updates in public m4 files weren't forgotten
- since last release (they should be updated in CVS along with commits that
- require it so that users can work with CVS snapshots).
+ since last release (they should be updated in git along with commits that
+ require it so that users can work with git snapshots).
* Update the LTDL_VERSION_INFO in libltdl/Makefile.inc for changes since
the last release.
-12. Alpha release note template
+13. Alpha release note template
===============================
To: libtool@gnu.org, autotools-announce@gnu.org
but is useable with @COMPATIBLE_AUTOTOOL_VERSIONS@ in your own
projects.
-Alternatively, you can fetch the unbootstrapped source code from
-anonymous cvs by using the following command:
+Alternatively, you can fetch the unbootstrapped source code with
+git by using the following command:
- $ cvs -z3 -d :pserver:anonymous@cvs.sv.gnu.org:/sources/libtool \
- co -r @CVS_RELEASE_TAG@ libtool
+ $ git clone git://git.savannah.gnu.org/libtool.git
+ $ cd libtool
+ $ git checkout @GIT_RELEASE_TAG@
You will then need to have recent (possibly as yet unreleased) versions
of Automake and Autoconf installed to bootstrap the checked out
-13. Full release note template
+14. Full release note template
==============================
To: info-gnu@gnu.org
but is useable with @COMPATIBLE_AUTOTOOL_VERSIONS@ in your own
projects.
-Alternatively, you can fetch the unbootstrapped source code from
-anonymous cvs by using the following command (just hit return when
-you are prompted for the password):
+Alternatively, you can fetch the unbootstrapped source code with
+git by using the following command:
- $ cvs -z3 -d :pserver:anonymous@cvs.sv.gnu.org:/sources/libtool \
- co -r @CVS_RELEASE_TAG@ libtool
+ $ git clone git://git.savannah.gnu.org/libtool.git
+ $ cd libtool
+ $ git checkout @GIT_RELEASE_TAG@
You will then need to have the latest release versions of Automake
(@AUTOMAKE_VERSION@) and Autoconf (@AUTOCONF_VERSION@) installed to
--
- Copyright (C) 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 2006, 2007, 2008 Free Software Foundation,
+ Inc.
Written by Gary V. Vaughan, 2004
This file is part of GNU Libtool. Report bugs to bug-libtool@gnu.org.
projects / thirdparty / libtool.git / commitdiff
