/[libtool]/libtool/HACKING
ViewVC logotype

Diff of /libtool/HACKING

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.6.2.12 by rwild, Mon Aug 8 06:48:06 2005 UTC revision 1.7 by gary, Fri Oct 22 10:32:13 2004 UTC
# Line 39  and is not part of a release distributio Line 39  and is not part of a release distributio
39          doc/          doc/
40              + fdl.texi              + fdl.texi
41          libltdl/          libltdl/
42              + COPYING.LIB              + COPYING.LESSER
43                + config.guess
44                + config.sub
45                + install-sh
46                + missing
47    The ones that are important for a release can be udated with,    The ones that are important for a release can be udated with,
48    `make -fMakefile.maint fetch' (or `make -f../Makefile.maint fetch'    `make -fMakefile.maint fetch' (or `make -f../Makefile.maint fetch'
49    if you are running from a VPATH build directory, where `../' is the    if you are running from a VPATH build directory, where `../' is the
# Line 48  and is not part of a release distributio Line 52  and is not part of a release distributio
52  * Changes other than bug fixes must be mentioned in NEWS  * Changes other than bug fixes must be mentioned in NEWS
53    
54    
55  3. Test Suite  2. Test Suite
56  =============  =============
57    
58  * Use "make check" liberally, on as many platforms as you can.  Use as  * Use "make check" liberally, on as many platforms as you can.  Use as
59    many compilers and linkers you can.    many compilers and linkers you can.
60    
61    
62  4. Naming  3. Naming
63  =========  =========
64    
65  * We've adopted the convention that exported Autoconf macros should be  * We've adopted the convention that exported Autoconf macros should be
# Line 71  and is not part of a release distributio Line 75  and is not part of a release distributio
75    with the `_lt_' macro namespace).    with the `_lt_' macro namespace).
76    
77    
78  5. Editing 'ChangeLog'  4. Editing `.am' Files
 ======================  
   
 * 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 colon, :.  
   
 * 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. Editing `.am' Files  
79  ======================  ======================
80    
81  * Always use $(...) and not ${...}  * Always use $(...) and not ${...}
# Line 186  yyyy-mm-dd  Name of Author  <email@addre Line 86  yyyy-mm-dd  Name of Author  <email@addre
86    
87  * Never use basename or dirname.  Instead use sed.  * Never use basename or dirname.  Instead use sed.
88    
89  * Do not use `cd' within back-quotes, use `$(lt__cd)' instead.  * Do not use `cd' within back-quotes, use `$(am__cd)' instead.
90    Otherwise the directory name may be printed, depending on CDPATH.    Otherwise the directory name may be printed, depending on CDPATH.
91    
92  * In general, if a loop is required, it should be silent.  Then the body  * In general, if a loop is required, it should be silent.  Then the body
93    of the loop itself should print each "important" command it runs.    of the loop itself should print each "important" command it runs.
94    
95    
96  7. Editing `.m4sh' Files  5. Editing `.m4sh' Files
97  ========================  ========================
98    
99  * Use shell functions, but be careful not to assume local scope for  * Use shell functions, but be careful not to assume local scope for
100    variable names.  Don't use `return', instead echo the result of a    variable names.  Don't use `return', instead echo the result of a
101    function and call it from within backquotes.    function and call it from within backquotes.
102    
103  * Function names should be prefixed `func_', the function header should  * Function names should be prefixed `func_'.
   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).  
104    
105  * For functions that are called frequently, if you need to return a  * For functions that are called frequently, if you need to return a
106    value, don't cause unneccessary forking of the shell using echo as    value, don't cause unneccessary forking of the shell using echo as
# Line 226  yyyy-mm-dd  Name of Author  <email@addre Line 114  yyyy-mm-dd  Name of Author  <email@addre
114    functions should begin indented by 4 spaces.    functions should begin indented by 4 spaces.
115    
116    
117  8. Editing `.m4' Files  6. Abstraction layers in libltdl
 ======================  
   
 * Be careful with both `echo' and `$ECHO'.  As the latter may be one of  
    echo  
    print -r  
    printf %s\n  
    $CONFIG_SHELL $0 --fallback-echo  
   it may not have more than one argument, its value may not be eval'ed  
   and the argument may not start with a `-'.  As a rule of thumb, use  
    echo ..              for literal (constant) strings without leading  
                         hyphen and no backslashes within,  
    $ECHO ".."           for strings without leading hyphen,  
    $ECHO "X.." | $Xsed  otherwise.  
   
   
 9. Abstraction layers in libltdl  
118  ================================  ================================
119    
120  * The libltdl API uses a layered approach to differentiate internal and  * The libltdl API uses a layered approach to differentiate internal and
# Line 326  yyyy-mm-dd  Name of Author  <email@addre Line 198  yyyy-mm-dd  Name of Author  <email@addre
198          lt__private.h          lt__private.h
199    
200    
201  10. Release Procedure  7. Release Procedure
202  ====================  ====================
203    
204  * If you are a libtool maintainer, but have not yet registered your  * If you are a libtool maintainer, but have not yet registered your
# Line 345  yyyy-mm-dd  Name of Author  <email@addre Line 217  yyyy-mm-dd  Name of Author  <email@addre
217    keys will be registered on ftp-upload.gnu.org and only then will you be    keys will be registered on ftp-upload.gnu.org and only then will you be
218    authorized to upload files to the FSF ftp machines.    authorized to upload files to the FSF ftp machines.
219    
 * 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.  
   
220  * Make sure you have wget installed.  * Make sure you have wget installed.
221    
222  * Make sure you have a copy of xdelta installed, and a copy of the previous  * Make sure you have a copy of xdelta installed, and a copy of the previous
223    release tarball in the build directory.    release tarball in the build directory.
224    
 * 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).  
   
 * Double check that libltdl version number updates 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).  
   
225  * Update the version number in configure.ac.  * Update the version number in configure.ac.
226    See http://www.gnu.org/software/libtool/contribute.html for details of    See http://www.gnu.org/software/libtool/contribute.html for details of
227    the numbering scheme.    the numbering scheme.
# Line 385  yyyy-mm-dd  Name of Author  <email@addre Line 242  yyyy-mm-dd  Name of Author  <email@addre
242    fetch new versions of the files that are maintained outside of    fetch new versions of the files that are maintained outside of
243    libtool.    libtool.
244    
245  * Run `make distcheck' and `make distcheck  * Run `make distcheck'.  If there are any problems, fix them and start
246    DISTCHECK_CONFIGURE_FLAGS=--disable-ltdl-install'.  If there are any    again.
   problems, fix them and start again.  
247    
248  * Run ./commit from the source tree.  * Run ./commit from the source tree.
249    
# Line 398  yyyy-mm-dd  Name of Author  <email@addre Line 254  yyyy-mm-dd  Name of Author  <email@addre
254    with release-$(VERSION) and generate the gpg signature files.    with release-$(VERSION) and generate the gpg signature files.
255    
256  * Run 'make -f[../]Makefile.maint deltas' (pass  * Run 'make -f[../]Makefile.maint deltas' (pass
257    LASTRELEASE=maj.min[.mic[alpha]] if needed) to create both diff and    LASTRELEASE=min.maj[.mic[alpha]] if needed) to create both diff and
258    xdelta files between the previous release tarball and the new with    xdelta files between the previous release tarball and the new with
259    detached gpg signature files and clear signed directive files.    detached gpg signature files and clear signed directive files.
260    
# Line 429  yyyy-mm-dd  Name of Author  <email@addre Line 285  yyyy-mm-dd  Name of Author  <email@addre
285    
286    
287    
288  11. Alpha release note template  7. Alpha release note template
289  ===============================  ==============================
290    
291  To: libtool@gnu.org, autotools-announce@gnu.org  To: libtool@gnu.org, autotools-announce@gnu.org
292  Subject: GNU Libtool @VERSION@ released (alpha release).  Subject: GNU Libtool @VERSION@ released (alpha release).
# Line 463  Here are the gpg detached signatures: Line 319  Here are the gpg detached signatures:
319  You should download the signature named after any tarball you download,  You should download the signature named after any tarball you download,
320  and then verify its integrity with, for example:  and then verify its integrity with, for example:
321    
322    gpg --verify libtool-@VERSION.tar.gz.sig    gpg --verify libtool-@VERSION.tar.gz.
323    
324  Here are the MD5 and SHA1 checksums:  Here are the MD5 and SHA1 checksums:
325    
# Line 502  output of any failed test groups, and th Line 358  output of any failed test groups, and th
358    
359    
360    
361  12. Full release note template  8. Full release note template
362  ==============================  =============================
363    
364  To: info-gnu@gnu.org  To: info-gnu@gnu.org
365  Cc: libtool@gnu.org, autotools-announce@gnu.org  Cc: libtool@gnu.org, autotools-announce@gnu.org
# Line 514  The Libtool Team is pleased to announce Line 370  The Libtool Team is pleased to announce
370    
371  GNU Libtool hides the complexity of using shared libraries behind a  GNU Libtool hides the complexity of using shared libraries behind a
372  consistent, portable interface. GNU Libtool ships with GNU libltdl,  consistent, portable interface. GNU Libtool ships with GNU libltdl,
373  which hides the complexity of loading dynamic runtime libraries  which hides the comlexity of loading dynamic runtime libraries
374  (modules) behind a consistent, portable interface.  (modules) behind a consistent, portable interface.
375    
376  This release has @SUMMARY_OF_IMPROVEMENTS_SINCE_LAST_RELEASE_ON_THIS_BRANCH@.  This release has @SUMMARY_OF_IMPROVEMENTS_SINCE_LAST_RELEASE_ON_THIS_BRANCH@.
# Line 550  Here are the gpg detached signatures: Line 406  Here are the gpg detached signatures:
406  You should download the signature named after any tarball you download,  You should download the signature named after any tarball you download,
407  and then verify its integrity with, for example:  and then verify its integrity with, for example:
408    
409    gpg --verify libtool-@VERSION.tar.gz.sig    gpg --verify libtool-@VERSION.tar.gz.
410    
411  Here are the MD5 and SHA1 checksums:  Here are the MD5 and SHA1 checksums:
412    
# Line 584  output of any failed test groups, and th Line 440  output of any failed test groups, and th
440    
441    
442  --  --
443  Copyright (C) 2004, 2005 Free Software Foundation, Inc.  Copyright (C) 2004 Free Software Foundation, Inc.
444    
445  The canonical source of this file is maintained with the  The canonical source of this file is maintained with the
446  GNU Libtool package.  Report bugs to bug-libtool@gnu.org.  GNU Libtool package.  Report bugs to bug-libtool@gnu.org.
# Line 606  General Public License for more details. Line 462  General Public License for more details.
462    
463  You should have received a copy of the GNU General Public License  You should have received a copy of the GNU General Public License
464  along with GNU Libtool; if not, write to the Free Software  along with GNU Libtool; if not, write to the Free Software
465  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
466  02110-1301  USA  02111-1307  USA
467    
468    
469  Local Variables:  Local Variables:

Legend:
Removed from v.1.6.2.12  
changed lines
  Added in v.1.7

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26