libtool/HACKING

GNU Libtool
***********

1. Introduction
===============

This file attempts to describe the processes we use to maintain libtool,
and is not part of a release distribution.

2. Maintenance Notes
====================

* If you incorporate a change from somebody on the net:
  If it is a large change, you must make sure they have signed the
  appropriate paperwork, and be sure to add their name and email
  address to THANKS

* If a change fixes a test, mention the test in the ChangeLog entry.

* If somebody reports a new bug, mention his name in the ChangeLog entry
  and in the test case you write.

* The correct response to most actual bugs is to write a new test case
  which demonstrates the bug.  Then fix the bug, re-run the test suite,
  and check everything in.

* Some files in the libtool package are not owned by libtool.  These
  files should never be edited here.  These files are:
	COPYING
	INSTALL
	config/
	    + config.guess
	    + config.sub
	    + depcomp
	    + install-sh
	    + mdate-sh
	    + missing
	    + texinfo.tex
	doc/
	    + fdl.texi
	libltdl/
	    + COPYING.LIB
  The ones that are important for a release can be udated with,
  `make -fMakefile.maint fetch' (or `make -f../Makefile.maint fetch'
  if you are running from a VPATH build directory, where `../' is the
  relative path to the directory with `configure' in it).

* Changes other than bug fixes must be mentioned in NEWS


3. Test Suite
=============

* 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.  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

* The new Autotest testsuite uses keywords to denote test features:
    autoconf		needs Autoconf
    automake		needs Automake
    libltdl		exercises the `libltdl' library
    libtool		exercises the `libtool' script
    libtoolize		exercises the `libtoolize' script
    recursive		runs the suite recursively, with a modified
			`libtool' script and with `-k libtool'
    CXX F77 FC GCJ	exercises a language other than C


4. Naming
=========

* We've adopted the convention that exported Autoconf macros should be
  named with a leading `LT_' and be documented in the libtool manual.
  Internal macros begin with `_LT_' if they are visible to aclocal, or
  potentially part of an AC_DEFUN/AC_REQUIRE path, or else `_lt_' if
  they are very low level.  This convention was only introduced just
  before libtool-2.0, so there may still be exceptions in the existing
  code.  But all new code should use it.

* All shell variables used internally by libtool's Autoconf macros
  should be named with the a leading `lt_' (not that they cannot clash
  with the `_lt_' macro namespace).


5. Editing 'ChangeLog'
======================

* When in doubt, check that emacs can syntax-color properly in
  change-log-mode.  And preferably use emacs 'C-x 4 a'
  (add-change-log-entry-other-window) to open ChangeLog with an
  appropriate new template.

* If this change is by a different author, or on a different date to the
  last entry start a new entry at the top of the file with the format
  (note two spaces between each field):

yyyy-mm-dd  Name of Author  <email@address>

*  If more than one person collaborated on the change, additional
   authors can be listed on subsequent lines, thus:

yyyy-mm-dd  Name of Main Author  <email@address>,
            Name of Contributor  <another@email.address>

* Where a change author did not supply a copyright assignment, but the
  changes they submitted were sufficiently trivial to commit in any case
  (see the GCS for guidelines on this), then flag this against their
  name in the header, thus:

yyyy-mm-dd  Name of Author  <email@address>  (tiny change)

* In ChangeLog.2004 and earlier, 'Name of Author' was sometimes the name
  of the author of the ChangeLog when the person who made the change
  being documented didn't supply one.   In that case separated from
  the previous field by a blank line and indented by 1 tab (note, only
  1 space between fields here) you will see:

	From Author of Actual Change <email@address>:

  As of now, don't do that anymore, since the GNU Coding Standards say
  that the author of the change must be credited in the main entry
  header for legal purposes.

* 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 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
  files can be listed here relative to $top_srcdir, and comma separated.
  Names of functions (or sections as appropriate) to which the change
  applies should be named inside parentheses and comma separated.  If
  this goes beyond column 72, then parens should be closed and re-opened
  on the next line:

	* file, another/file, test/testcases/foo.test (func_foo)
	(func_bar, func_baz): Description of changes.

* If the change does not apply to particular functions (or sections),
  the section list can be omitted:

	* file, another/file, test/testcases/foo.test: General changes.

* If the changes are particular to certain architectures, they should be
  listed after the functions in square brackets:

	* file, another/file (func_foo) [linux, solaris]: Description of
	changes.

* Subsequent changes in other files that are related to the same overall
  enhancement or bugfix should be listed concurrently, without blank
  lines.  Always start a fresh line for a new file:

	* file, another/file (func_foo) [linux, solaris]: Description of
	changes.
	* doc/foo.texi (Invoking Foo): Document.
	* NEWS: Updated.

* If the change is in response to a problem reported by someone other
  than the author, then credit them at the end of the description with:

	Reported by Reporter Name <email@address>.

* See the GNU Coding Standards document for more details on ChangeLog
  formatting.


2005-01-08  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>  (tiny change),
            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.

	* HACKING: Updated copyright.  This isn't attached to a
	particular section of the file, so it comes first.
	(Editing 'ChangeLog'): New section.  This applies to the same
	file, but since it applies to a particular section it starts on
	a new line.
	(Introduction, Maintenance Notes, Test Suite, Naming)
	(Editing '.am' Files): If I had changed all these sections in
	the same way, I can list them like this, being careful to close
	and reopen the parentheses when starting a new line.  The colon
	only comes after the last section before this description.
	* 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>

* 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.


7. Editing `.am' Files
======================

* Always use $(...) and not ${...}

* Use `:', not `true'.  Use `exit 1', not `false'.

* Use `##' comments liberally.  Comment anything even remotely unusual.

* Never use basename or dirname.  Instead use sed.

* Do not use `cd' within back-quotes, use `$(lt__cd)' instead.
  Otherwise the directory name may be printed, depending on CDPATH.

* In general, if a loop is required, it should be silent.  Then the body
  of the loop itself should print each "important" command it runs.

* Use 4 extra spaces to indent continued dependencies.

* One needs to remember that for our whole logic for the different
  libltdl modes to function correctly, the thing we need to ensure
  *before the client runs libtoolize*, is that the subpackage case is
  correct (because all files may be symlinked there).  All others can
  and will be fixed in the `libtoolize --ltdl --(non)recursive' stage.


8. Editing `.m4sh' Files
========================

* Use shell functions, but be careful not to assume local scope for
  variable names.  Don't use `return', instead echo the result of a
  function and call it from within backquotes.

* Function names should be prefixed `func_', the function header should
  look like this:

  # func_foo [ OPTIONS ]
  # Description of what func_foo does and returns.
  func_foo ()
  {
      $opt_debug
      # contents of func_foo ...
  }

  The `$opt_debug' is used to enable shell tracing (Korn shells reset
  this on function entry).

* For functions that are called frequently, if you need to return a
  value, don't cause unneccessary forking of the shell using echo as
  described above; instead set the return value in a variable named
  after the called function with a suffix of `_result'.  For example
  the function `func_quote_for_eval' stores its return value in the
  variable `$func_quote_for_eval_result'.

* Although sh-indentation is set to 2 (by the `Local Variables:' block
  at the end of .m4sh files), the left margin of the body of shell
  functions should begin indented by 4 spaces.

* Where there are large blocks of shell code with no m4 or m4sh
  expansions, put the entire block in an M4SH_VERBATIM call.  This
  saves both on copy-and-paste errors, and needing to remember to
  internally double the m4 quoting characters:

  M4SH_VERBATIM([[
  my_sed_long_opt='1s/^\(--[^=]*\)=.*/\1/;q'
  ...
  ]])


9. Editing `.m4' Files
======================

* Be careful with both `echo' and `$ECHO'.  As the latter may be one of
   print -r --
   printf %s\n
   func_fallback_echo
  it may not have more than one argument and its value may not be
  eval'ed.  However, the argument may start with a `-' and contain
  backslashes.  As a rule of thumb, use
   echo ..		for literal (constant) strings without leading
			hyphen and no backslashes within,
   $ECHO ".."		otherwise.
   func_echo_all	when multiple arguments are present, or when
			placed in an eval'ed variable.

* The Autoconf manual says that giving an empty parameter is equivalent
  to not giving it at all.  (In particular, the Autoconf manual doesn't
  explain that "FOO()" is calling macro FOO with one empty parameter.)
  To prevent misunderstanding, we should use m4_ifval to check whether
  a parameter is empty, and not $# to check for the number of parameters.

* Any time we add a macro to an older version, lt~obsolete.m4 needs to
  be updated in all newer versions.


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
  consistent, files in a given layer may only use APIs from files in the
  lower layers.  The ASCII art boxes below represent this stack, from
  top to bottom...

* But first, outside of the stack, there is a convenience header that
  defines the internal interfaces (as evidenced by the `lt__' prefix to
  the filename!) shared between implementation files in the stack, that
  are however not exported to libltdl clients:

	,-------------.
	|lt__private.h|
	`-------------'

* The top layer of the stack is the libltdl API proper, which includes
  the relevant subsystems automatically.  Clients of libltdl need only
  invoke:

  #include <ltdl.h>

	,------.
	|ltdl.h|
	+------+
	|ltdl.c|
	`------'

* The next layer is comprised of the subsystems of the exported libltdl
  API, which are implemented by files that are named with a leading `lt_'
  (single underscore!):

	,------------v---------------.
	| lt_error.h | lt_dlloader.h |
	+------------+---------------+
	| lt_error.c | lt_dlloader.c |
	`------------^---------------'

* The next file is used both by the headers that implement it (in which
  case its function is to avoid namespace clashes when linking with the
  GNU C library proper) and is included by code that wants to program
  against a glibc-like interface, in which case it serves to pull in all
  the glibc-like functionality used by libltdl with a simple:

    #include <libltdl/lt__glibc.h>

  It consists of a single file:

	,-----------.
	|lt__glibc.h|
	`-----------'

* Next to last is the libc abstraction layer, which provides a uniform
  API to various system libc interfaces that differ between hosts
  supported by libtool.  Typically, the files that implement this layer
  begin:

    #if defined(LT_CONFIG_H)
    #  include LT_CONFIG_H
    #else
    #  include <config.h>
    #endif
    #include "lt_system.h"

  Or if they are installed headers that must work outside the libtool
  source tree, simply:

    #include <libltdl/lt_system.h>

  This layer's interface is defined by files that are usually named with
  a leading `lt__':

	,--------------v-------------v------------v--------v---------.
	| lt__dirent.h | lt__alloc.h | lt__strl.h | argz.h | slist.h |
	+--------------+-------------+------------+--------+---------+
	| lt__dirent.c | lt__alloc.c | lt__strl.c | argz.c | slist.c |
	`--------------^-------------^------------^--------^---------'

  (argz.h and slist.h are used independently of libltdl in other projects)

* At the bottom of the stack we have the system abstraction layer,
  which tries to smooth over the cracks where there are differences
  between host systems and compilers.  config.h is generated at
  configure time and is not installed; lt_system.h is an installed
  file and cannot use macros from config.h:

	,-----------.
	|../config.h|
	`-----------'

	,-----------.
	|lt_system.h|
	`-----------'

* Tacked on the side of this stack, attached via the lt_dlloader.h
  definitions are the various implementation modules for run-time module
  loading: preopen.c, dlopen.c etc.


11. Licensing Rules
===================

GNU Libtool uses 3 different licenses for various of the files distributed
herein, with several variations on license text.  It is important that
you use the correct license text in each new file added.  Here are the
texts along with some notes on when each is appropriate.  Appropriate
commenting (shell, C etc) and decoration (m4sh etc) assumed throughout.



11.1. Notice preservation

Autoconf macros and files used to generate them need this license, along
with files such as HACKING, NEWS, README, README.alpha, TODO and
ChangeLogs:

   Copyright (C) <year list> Free Software Foundation, Inc.
   Written by <author>, <year>

Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved.  This file is offered as-is,
without warranty of any kind.



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
below:

   Copyright (C) <year list> Free Software Foundation, Inc.
   Written by <author>, <year>

   This file is part of GNU Libtool.

GNU Libtool 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 of
the License, or (at your option) any later version.

GNU Libtool is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
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 GNU Libtool; see the file COPYING.  If not, a copy
can be downloaded from  http://www.gnu.org/licenses/gpl.html,
or obtained by writing to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.



11.3. GPL with self extracting version

Some of the sources built atop the getopt.m4sh framework use
func_version() to extract their --version output from the copyright
block.  Those files also need the --version copyright text paragraph as
follows:

   <program name> (GNU @PACKAGE@) <version number>
   Written by <author> <email address>.

   This file is part of <parent package name>.

Copyright (C) <year list> Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

<program name> 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 of the License, or
(at your option) any later version.

<program name> is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
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 <program name>; see the file COPYING.  If not, a copy
can be downloaded from http://www.gnu.org/licenses/gpl.html,
or obtained by writing to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.



11.4. 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
exception clause so that it can be redistributed by other projects
that use libtool:

  <program name> (GNU @PACKAGE@@TIMESTAMP@) <version number>
  Written by <author> <email address>.

  This file is part of GNU Libtool.

Copyright (C) <year list> Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

<program name> 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 of the License, or
(at your option) any later version.

As a special exception to the GNU General Public License,
if you distribute this file as part of a program or library that
is built using GNU Libtool, you may include this file under the
same distribution terms that you use for the rest of that program.

<program name> is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
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 <program name>; see the file COPYING.  If not, a copy
can be downloaded from http://www.gnu.org/licenses/gpl.html,
or obtained by writing to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.



11.5. 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
the following license text citing the LGPL along with Libtool's special
exception clause:

   Copyright (C) <year list> Free Software Foundation, Inc.
   Written by <author>, <year>

   NOTE: The canonical source of this file is maintained with the
   GNU Libtool package.  Report bugs to bug-libtool@gnu.org.

GNU Libltdl is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.

As a special exception to the GNU Lesser General Public License,
if you distribute this file as part of a program or library that
is built using GNU Libtool, you may include this file under the
same distribution terms that you use for the rest of that program.

GNU Libltdl is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public
License along with GNU Libltdl; see the file COPYING.LIB.  If not, a
copy can be downloaded from  http://www.gnu.org/licenses/lgpl.html,
or obtained by writing to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.


12. Release Procedure
=====================

* If you are a libtool maintainer, but have not yet registered your
  gpg public key and (preferred) email address with the FSF, send an
  email, preferably GPG-signed, to <ftp-upload@gnu.org> that includes
  the following:

    (a) name of package(s) that you are the maintainer for, and your
        preferred email address.

    (b) an ASCII armored copy of your GnuPG key, as an attachment.
	("gpg --export -a YOUR_KEY_ID > mykey.asc" should give you
	this.)

  When you have received acknowledgement of your message, the proper GPG
  keys will be registered on ftp-upload.gnu.org and only then will you be
  authorized to upload files to the FSF ftp machines.

* If you do not have access to the mailing list administrative interface,
  approach the list owners for the password.  Be sure to check the lists
  (esp. bug-libtool) for outstanding bug reports also in the list of
  pending moderation requests.

* Make sure you have wget and lzma installed.

* 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 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.

* Update the version number in configure.ac and libltdl/configure.ac.
  See http://www.gnu.org/software/libtool/contribute.html for details of
  the numbering scheme.

* Update NEWS, ChangeLog.

* Until the bug that leaks developer tool paths into the release tarballs
  from ./bootstrap is fixed, make sure the right tools are first in your
  PATH and then:
	export EGREP=egrep
	export FGREP=fgrep
	export GREP=grep
	export MAKE=make
	export SED=sed

* Run ./bootstrap.

* Run ./configure (or create a build directory first and run configure
  from there, if you want to keep the build tree separate).

* Run `make -fMakefile.maint fetch' (or `make -f../Makefile.maint fetch'
  if you are running from a VPATH build directory, where `../' is the
  relative path to the directory with `configure' in it), which will
  fetch new versions of the files that are maintained outside of
  libtool.

* Run `make distcheck'
  and `make distcheck DISTCHECK_CONFIGURE_FLAGS=--disable-ltdl-install'
  and `make distcheck DISTCHECK_CONFIGURE_FLAGS=--program-prefix=g'
  and `make distcheck CC=g++'
  If there are any problems, fix them and start again.

* Run `./commit -p' from the source tree.

* Run `make -fMakefile.maint git-dist' (or `make -f../Makefile.maint
  git-dist' if you are running from a VPATH build directory, where `../'
  is the relative path to the directory with `configure' in it), which
  will build a release tarball (with `make distcheck'), tag the tree
  with release-$(VERSION) and generate the gpg signature files.

* Run 'make -f[../]Makefile.maint diffs' (pass
  LASTRELEASE=maj.min[.mic[alpha]] if needed) to create diff files
  between the previous release tarball and the new with detached gpg
  signature files and clear signed directive files.

* If not an alpha, generate with `make -f[../]Makefile.maint
  web-manual'.

* Upload release tarballs and diff files, plus their associated
  detached gpg signature files and clear signed directive files to
  ftp-upload.gnu.org.  If the upload is destined for ftp.gnu.org, then the
  files should be placed in the /incoming/ftp directory.  If the upload is
  an alpha release destined for alpha.gnu.org, then the files should be
  placed in the /incoming/alpha directory.

* Update version number in configure.ac and libltdl/configure.ac to next
  alpha number.  See http://www.gnu.org/software/libtool/contribute.html
  for details of the numbering scheme.

* Update NEWS, ChangeLog.

* Run `./commit -p --tags', to push the new changes and tags to origin.

* Update the webpages, libtool.html will need to indicate the latest
  release number.

* If not an alpha, upload new manual pages you created earlier in
  doc/manual using cvs to here:
  <yourusername>@cvs.savannah.gnu.org:/webcvs/libtool

* In the build directory, run `Make -f[../]Makefile.maint announce-gen'.

* Make sure the source directory has an appropriate .announcerc, along
  the lines of:

    --bootstrap-tools='autoconf,automake'
    --gpg-key-id={the id of the key you signed the tarballs with}
    --header 'From: {your name} <{your email address}>
    --header 'To: Libtool List <libtool@gnu.org>'
    --header 'Cc: Autotools Announce List <autotools-announce@gnu.org>'
    --header 'Reply-To: Libtool Bugs <bug-libtool@gnu.org>'
    --message 'GNU Libtool hides the complexity of using shared'
    --message 'libraries behind a consistent, portable interface.'
    --message 'GNU Libtool ships with GNU libltdl, which hides the'
    --message 'complexity of loading dynamic runtime libraries'
    --message '(modules) behind a consistent, portable interface.'
    --signature

* Check the release announcement with:

    ./announce-gen -r -o --prev=LASTRELEASE alpha

  or for a stable release:

    ./announce-gen -r -o -h 'Cc: info-gnu@gnu.org' --prev=LASTRELEASE stable

  When you're happy with the announcement text, post it by rerunning the
  command with `-p' instead of `-o'.

* Post a copy of the release announcement to savannah news:
  https://savannah.gnu.org/news/submit.php?group=libtool
  which will automatically propogate to http://planet.gnu.org.

-- 
  Copyright (C) 2004, 2005, 2006, 2007, 2008 Free Software Foundation,
  Inc.
  Written by Gary V. Vaughan, 2004

  This file is part of GNU Libtool.

Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved.  This file is offered as-is,
without warranty of any kind.

Local Variables:
mode: text
fill-column: 72
End:
vim:tw=72