/[libtool]/libtool/HACKING
ViewVC logotype

Contents of /libtool/HACKING

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.43 - (show annotations) (download)
Sun May 4 21:41:00 2008 UTC (16 years ago) by gary
Branch: MAIN
CVS Tags: HEAD
Changes since 1.42: +0 -0 lines
FILE REMOVED
Development has moved to git.

1 GNU Libtool
2 ***********
3
4 1. Introduction
5 ===============
6
7 This file attempts to describe the processes we use to maintain libtool,
8 and is not part of a release distribution.
9
10 2. Maintenance Notes
11 ====================
12
13 * If you incorporate a change from somebody on the net:
14 If it is a large change, you must make sure they have signed the
15 appropriate paperwork, and be sure to add their name and email
16 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.
22
23 * The correct response to most actual bugs is to write a new test case
24 which demonstrates the bug. Then fix the bug, re-run the test suite,
25 and check everything in.
26
27 * Some files in the libtool package are not owned by libtool. These
28 files should never be edited here. These files are:
29 COPYING
30 INSTALL
31 config/
32 + config.guess
33 + config.sub
34 + depcomp
35 + install-sh
36 + mdate-sh
37 + missing
38 + texinfo.tex
39 doc/
40 + fdl.texi
41 libltdl/
42 + COPYING.LIB
43 The ones that are important for a release can be udated with,
44 `make -fMakefile.maint fetch' (or `make -f../Makefile.maint fetch'
45 if you are running from a VPATH build directory, where `../' is the
46 relative path to the directory with `configure' in it).
47
48 * Changes other than bug fixes must be mentioned in NEWS
49
50
51 3. Test Suite
52 =============
53
54 * When writing tests, make sure the link invocation (first argument to
55 AT_CHECK) is on a single line so that 'testsuite -x' displays the
56 whole thing.
57
58 * Use
59 make check TESTSUITEFLAGS=-V
60 make check-local
61 liberally, on as many platforms as you can. Use as many compilers and
62 linkers you can.
63
64 * The new Autotest testsuite uses keywords to denote test features:
65 autoconf needs Autoconf
66 automake needs Automake
67 libltdl exercises the `libltdl' library
68 libtool exercises the `libtool' script
69 libtoolize exercises the `libtoolize' script
70 recursive runs the suite recursively, with a modified
71 `libtool' script and with `-k libtool'
72 CXX F77 FC GCJ exercises a language other than C
73
74
75 4. Naming
76 =========
77
78 * We've adopted the convention that exported Autoconf macros should be
79 named with a leading `LT_' and be documented in the libtool manual.
80 Internal macros begin with `_LT_' if they are visible to aclocal, or
81 potentially part of an AC_DEFUN/AC_REQUIRE path, or else `_lt_' if
82 they are very low level. This convention was only introduced just
83 before libtool-2.0, so there may still be exceptions in the existing
84 code. But all new code should use it.
85
86 * All shell variables used internally by libtool's Autoconf macros
87 should be named with the a leading `lt_' (not that they cannot clash
88 with the `_lt_' macro namespace).
89
90
91 5. Editing 'ChangeLog'
92 ======================
93
94 * When in doubt, check that emacs can syntax-color properly in
95 change-log-mode. And preferably use emacs 'C-x 4 a'
96 (add-change-log-entry-other-window) to open ChangeLog with an
97 appropriate new template.
98
99 * If this change is by a different author, or on a different date to the
100 last entry start a new entry at the top of the file with the format
101 (note two spaces between each field):
102
103 yyyy-mm-dd Name of Author <email@address>
104
105 * If more than one person collaborated on the change, additional
106 authors can be listed on subsequent lines, thus:
107
108 yyyy-mm-dd Name of Main Author <email@address>,
109 Name of Contributor <another@email.address>
110
111 * Where a change author did not supply a copyright assignment, but the
112 changes they submitted were sufficiently trivial to commit in any case
113 (see the GCS for guidelines on this), then flag this against their
114 name in the header, thus:
115
116 yyyy-mm-dd Name of Author <email@address> (tiny change)
117
118 * In ChangeLog.2004 and earlier, 'Name of Author' was sometimes the name
119 of the author of the ChangeLog when the person who made the change
120 being documented didn't supply one. In that case separated from
121 the previous field by a blank line and indented by 1 tab (note, only
122 1 space between fields here) you will see:
123
124 From Author of Actual Change <email@address>:
125
126 As of now, don't do that anymore, since the GNU Coding Standards say
127 that the author of the change must be credited in the main entry
128 header for legal purposes.
129
130 * Preferably the next part should be a description of the overall
131 purpose of the change, separated from the header by a blank line,
132 indented by 1 tab, and filled at column 72. The last character of the
133 description should be a colon, :.
134
135 * Changes to each file come next. Each new file starts on a new line,
136 indented by 1 tab and starting with an asterisk and a space. Multiple
137 files can be listed here relative to $top_srcdir, and comma separated.
138 Names of functions (or sections as appropriate) to which the change
139 applies should be named inside parentheses and comma separated. If
140 this goes beyond column 72, then parens should be closed and re-opened
141 on the next line:
142
143 * file, another/file, test/testcases/foo.test (func_foo)
144 (func_bar, func_baz): Description of changes.
145
146 * If the change does not apply to particular functions (or sections),
147 the section list can be omitted:
148
149 * file, another/file, test/testcases/foo.test: General changes.
150
151 * If the changes are particular to certain architectures, they should be
152 listed after the functions in square brackets:
153
154 * file, another/file (func_foo) [linux, solaris]: Description of
155 changes.
156
157 * Subsequent changes in other files that are related to the same overall
158 enhancement or bugfix should be listed concurrently, without blank
159 lines. Always start a fresh line for a new file:
160
161 * file, another/file (func_foo) [linux, solaris]: Description of
162 changes.
163 * doc/foo.texi (Invoking Foo): Document.
164 * NEWS: Updated.
165
166 * If the change is in response to a problem reported by someone other
167 than the author, then credit them at the end of the description with:
168
169 Reported by Reporter Name <email@address>.
170
171 * See the GNU Coding Standards document for more details on ChangeLog
172 formatting.
173
174
175 2005-01-08 Ralf Wildenhues <Ralf.Wildenhues@gmx.de> (tiny change),
176 Peter O'Gorman <peter@pogma.com>
177
178 This is the overall description of the purpose of this change
179 and any useful background for a model ChangeLog entry:
180
181 * HACKING: Updated copyright. This isn't attached to a
182 particular section of the file, so it comes first.
183 (Editing 'ChangeLog'): New section. This applies to the same
184 file, but since it applies to a particular section it starts on
185 a new line.
186 (Introduction, Maintenance Notes, Test Suite, Naming)
187 (Editing '.am' Files): If I had changed all these sections in
188 the same way, I can list them like this, being careful to close
189 and reopen the parentheses when starting a new line. The colon
190 only comes after the last section before this description.
191 * NEWS: Updated.
192 Reported by Bob Friesenhahn <bfriesen@simple.dallas.tx.us>.
193
194
195 6. Editing `.am' Files
196 ======================
197
198 * Always use $(...) and not ${...}
199
200 * Use `:', not `true'. Use `exit 1', not `false'.
201
202 * Use `##' comments liberally. Comment anything even remotely unusual.
203
204 * Never use basename or dirname. Instead use sed.
205
206 * Do not use `cd' within back-quotes, use `$(lt__cd)' instead.
207 Otherwise the directory name may be printed, depending on CDPATH.
208
209 * In general, if a loop is required, it should be silent. Then the body
210 of the loop itself should print each "important" command it runs.
211
212 * Use 4 extra spaces to indent continued dependencies.
213
214 * One needs to remember that for our whole logic for the different
215 libltdl modes to function correctly, the thing we need to ensure
216 *before the client runs libtoolize*, is that the subpackage case is
217 correct (because all files may be symlinked there). All others can
218 and will be fixed in the `libtoolize --ltdl --(non)recursive' stage.
219
220
221 7. Editing `.m4sh' Files
222 ========================
223
224 * Use shell functions, but be careful not to assume local scope for
225 variable names. Don't use `return', instead echo the result of a
226 function and call it from within backquotes.
227
228 * Function names should be prefixed `func_', the function header should
229 look like this:
230
231 # func_foo [ OPTIONS ]
232 # Description of what func_foo does and returns.
233 func_foo ()
234 {
235 $opt_debug
236 # contents of func_foo ...
237 }
238
239 The `$opt_debug' is used to enable shell tracing (Korn shells reset
240 this on function entry).
241
242 * For functions that are called frequently, if you need to return a
243 value, don't cause unneccessary forking of the shell using echo as
244 described above; instead set the return value in a variable named
245 after the called function with a suffix of `_result'. For example
246 the function `func_quote_for_eval' stores its return value in the
247 variable `$func_quote_for_eval_result'.
248
249 * Although sh-indentation is set to 2 (by the `Local Variables:' block
250 at the end of .m4sh files), the left margin of the body of shell
251 functions should begin indented by 4 spaces.
252
253 * Where there are large blocks of shell code with no m4 or m4sh
254 expansions, put the entire block in an M4SH_VERBATIM call. This
255 saves both on copy-and-paste errors, and needing to remember to
256 internally double the m4 quoting characters:
257
258 M4SH_VERBATIM([[
259 my_sed_long_opt='1s/^\(--[^=]*\)=.*/\1/;q'
260 ...
261 ]])
262
263
264 8. Editing `.m4' Files
265 ======================
266
267 * Be careful with both `echo' and `$ECHO'. As the latter may be one of
268 echo
269 print -r
270 printf %s\n
271 $CONFIG_SHELL $0 --fallback-echo
272 it may not have more than one argument, its value may not be eval'ed
273 and the argument may not start with a `-'. As a rule of thumb, use
274 echo .. for literal (constant) strings without leading
275 hyphen and no backslashes within,
276 $ECHO ".." for strings without leading hyphen,
277 $ECHO "X.." | $Xsed otherwise.
278
279 * The Autoconf manual says that giving an empty parameter is equivalent
280 to not giving it at all. (In particular, the Autoconf manual doesn't
281 explain that "FOO()" is calling macro FOO with one empty parameter.)
282 To prevent misunderstanding, we should use m4_ifval to check whether
283 a parameter is empty, and not $# to check for the number of parameters.
284
285 * Any time we add a macro to an older version, lt~obsolete.m4 needs to
286 be updated in all newer versions.
287
288
289 9. Abstraction layers in libltdl
290 ================================
291
292 * The libltdl API uses a layered approach to differentiate internal and
293 external interfaces, among other things. To keep the abstraction
294 consistent, files in a given layer may only use APIs from files in the
295 lower layers. The ASCII art boxes below represent this stack, from
296 top to bottom...
297
298 * But first, outside of the stack, there is a convenience header that
299 defines the internal interfaces (as evidenced by the `lt__' prefix to
300 the filename!) shared between implementation files in the stack, that
301 are however not exported to libltdl clients:
302
303 ,-------------.
304 |lt__private.h|
305 `-------------'
306
307 * The top layer of the stack is the libltdl API proper, which includes
308 the relevant subsystems automatically. Clients of libltdl need only
309 invoke:
310
311 #include <ltdl.h>
312
313 ,------.
314 |ltdl.h|
315 +------+
316 |ltdl.c|
317 `------'
318
319 * The next layer is comprised of the subsystems of the exported libltdl
320 API, which are implemented by files that are named with a leading `lt_'
321 (single underscore!):
322
323 ,------------v---------------.
324 | lt_error.h | lt_dlloader.h |
325 +------------+---------------+
326 | lt_error.c | lt_dlloader.c |
327 `------------^---------------'
328
329 * The next file is used both by the headers that implement it (in which
330 case its function is to avoid namespace clashes when linking with the
331 GNU C library proper) and is included by code that wants to program
332 against a glibc-like interface, in which case it serves to pull in all
333 the glibc-like functionality used by libltdl with a simple:
334
335 #include <libltdl/lt__glibc.h>
336
337 It consists of a single file:
338
339 ,-----------.
340 |lt__glibc.h|
341 `-----------'
342
343 * Next to last is the libc abstraction layer, which provides a uniform
344 API to various system libc interfaces that differ between hosts
345 supported by libtool. Typically, the files that implement this layer
346 begin:
347
348 #if defined(LT_CONFIG_H)
349 # include LT_CONFIG_H
350 #else
351 # include <config.h>
352 #endif
353 #include "lt_system.h"
354
355 Or if they are installed headers that must work outside the libtool
356 source tree, simply:
357
358 #include <libltdl/lt_system.h>
359
360 This layer's interface is defined by files that are usually named with
361 a leading `lt__':
362
363 ,--------------v-------------v------------v--------v---------.
364 | lt__dirent.h | lt__alloc.h | lt__strl.h | argz.h | slist.h |
365 +--------------+-------------+------------+--------+---------+
366 | lt__dirent.c | lt__alloc.c | lt__strl.c | argz.c | slist.c |
367 `--------------^-------------^------------^--------^---------'
368
369 (argz.h and slist.h are used independently of libltdl in other projects)
370
371 * At the bottom of the stack we have the system abstraction layer,
372 which tries to smooth over the cracks where there are differences
373 between host systems and compilers. config.h is generated at
374 configure time and is not installed; lt_system.h is an installed
375 file and cannot use macros from config.h:
376
377 ,-----------.
378 |../config.h|
379 `-----------'
380
381 ,-----------.
382 |lt_system.h|
383 `-----------'
384
385 * Tacked on the side of this stack, attached via the lt_dlloader.h
386 definitions are the various implementation modules for run-time module
387 loading: preopen.c, dlopen.c etc.
388
389
390 10. Licensing Rules
391 ===================
392
393 GNU Libtool uses 3 different licenses for various of the files distributed
394 herein, with 7 variations on license text. It is important that you use
395 the correct license text in each new file added. Here are the texts
396 along with some notes on when each is appropriate. Appropriate commenting
397 (shell, C etc) and decoration (m4sh etc) assumed throughout.
398
399 10.1. Notice preservation
400
401 Autoconf macros and files used to generate them need this license:
402
403 Copyright (C) <year list> Free Software Foundation, Inc.
404 Written by <author>, <year>
405
406 This file is free software; the Free Software Foundation gives
407 unlimited permission to copy and/or distribute it, with or without
408 modifications, as long as this notice is preserved.
409
410
411
412 10.2. GPL
413
414 Everything else in the distribution has the following license text
415 unless there is good reason to use one of the other license texts
416 below:
417
418 Copyright (C) <year list> Free Software Foundation, Inc.
419 Written by <author>, <year>
420
421 This file is part of GNU Libtool.
422
423 GNU Libtool is free software; you can redistribute it and/or
424 modify it under the terms of the GNU General Public License as
425 published by the Free Software Foundation; either version 2 of
426 the License, or (at your option) any later version.
427
428 GNU Libtool is distributed in the hope that it will be useful,
429 but WITHOUT ANY WARRANTY; without even the implied warranty of
430 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
431 GNU General Public License for more details.
432
433 You should have received a copy of the GNU General Public License
434 along with GNU Libtool; see the file COPYING. If not, a copy
435 can be downloaded from http://www.gnu.org/licenses/gpl.html,
436 or obtained by writing to the Free Software Foundation, Inc.,
437 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
438
439
440
441 10.3. GPL with Libtool exception clause
442
443 At the moment only `libltdl/README' needs the exception clause to
444 allow projects that distribute a copy of the libltdl sources to also
445 redistribute the README:
446
447
448 Copyright (C) <year list> Free Software Foundation, Inc.
449 Written by <author>, <year>
450
451 This file is part of GNU Libtool.
452
453 GNU Libtool is free software; you can redistribute it and/or
454 modify it under the terms of the GNU General Public License as
455 published by the Free Software Foundation; either version 2 of
456 the License, or (at your option) any later version.
457
458 As a special exception to the GNU General Public License,
459 if you distribute this file as part of a program or library that
460 is built using GNU Libtool, you may include this file under the
461 same distribution terms that you use for the rest of that program.
462
463 GNU Libtool is distributed in the hope that it will be useful,
464 but WITHOUT ANY WARRANTY; without even the implied warranty of
465 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
466 GNU General Public License for more details.
467
468 You should have received a copy of the GNU General Public License
469 along with GNU Libtool; see the file COPYING. If not, a copy
470 can be downloaded from http://www.gnu.org/licenses/gpl.html,
471 or obtained by writing to the Free Software Foundation, Inc.,
472 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
473
474
475
476 10.4. GPL with Cvs-utils exception clause
477
478 GNU Libtool imports some m4sh infrastructure from the GNU Cvs-utils
479 project, namely `getopt.m4sh' and `general.m4sh'. Those files use
480 the GPL with their own exception clause as follows:
481
482 Copyright (C) <year list> Free Software Foundation, Inc.
483 Written by <author>, <year>
484
485 This file is part of GNU Cvs-utils.
486
487 GNU Cvs-utils is free software; you can redistribute it and/or
488 modify it under the terms of the GNU General Public License as
489 published by the Free Software Foundation; either version 2 of
490 the License, or (at you option) any later version.
491
492 As a special exception to the GNU General Public License, if you
493 distribute this file as part of a program or library that contains
494 a configuration script generated by Autoconf, you may include this
495 file under the same distribution terms that you use for the rest
496 of that program.
497
498 GNU Cvs-utils is distributed in the hope that it will be useful,
499 but WITHOUT ANY WARRANTY; without even the implied warranty of
500 MERCHANTABILITY or FITNES FOR A PARTICULAR PURPOSE. See the GNU
501 General Public License for more details.
502
503 You should have received a copy of the GNU General Public License
504 along with GNU Libtool; see the file COPYING. If not, a copy
505 can be downloaded from http://www.gnu.org/licenses/gpl.html,
506 or obtained by writing to the Free Software Foundation, Inc.,
507 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
508
509
510
511 10.5. GPL with self extracting version
512
513 Some of the sources built atop Cvs-utils' m4sh framework use
514 getopt.m4sh:func_version() to extract their --version output from
515 the copyright block. Those files also need the --version copyright
516 text paragraph as follows:
517
518 <program name> (GNU @PACKAGE@) <version number>
519 Written by <author> <email address>.
520
521 This file is part of <parent package name>.
522
523 Copyright (C) <year list> Free Software Foundation, Inc.
524 This is free software; see the source for copying conditions. There is NO
525 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
526
527 <program name> is free software; you can redistribute it and/or modify
528 it under the terms of the GNU General Public License as published by
529 the Free Software Foundation; either version 2 of the License, or
530 (at your option) any later version.
531
532 <program name> is distributed in the hope that it will be useful, but
533 WITHOUT ANY WARRANTY; without even the implied warranty of
534 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
535 GNU General Public License for more details.
536
537 You should have received a copy of the GNU General Public License
538 along with <program name>; see the file COPYING. If not, a copy
539 can be downloaded from http://www.gnu.org/licenses/gpl.html,
540 or obtained by writing to the Free Software Foundation, Inc.,
541 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
542
543
544
545 10.6. GPL with self extracting version and Libtool exception clause
546
547 Although the libtool script is generated from `ltmain.m4sh' according
548 to the rules in the preceding subsection, it also needs the Libtool
549 exception clause so that it can be redistributed by other projects
550 that use libtool:
551
552 <program name> (GNU @PACKAGE@@TIMESTAMP@) <version number>
553 Written by <author> <email address>.
554
555 This file is part of GNU Libtool.
556
557 Copyright (C) <year list> Free Software Foundation, Inc.
558 This is free software; see the source for copying conditions. There is NO
559 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
560
561 <program name> is free software; you can redistribute it and/or modify
562 it under the terms of the GNU General Public License as published by
563 the Free Software Foundation; either version 2 of the License, or
564 (at your option) any later version.
565
566 As a special exception to the GNU General Public License,
567 if you distribute this file as part of a program or library that
568 is built using GNU Libtool, you may include this file under the
569 same distribution terms that you use for the rest of that program.
570
571 <program name> is distributed in the hope that it will be useful, but
572 WITHOUT ANY WARRANTY; without even the implied warranty of
573 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
574 GNU General Public License for more details.
575
576 You should have received a copy of the GNU General Public License
577 along with <program name>; see the file COPYING. If not, a copy
578 can be downloaded from http://www.gnu.org/licenses/gpl.html,
579 or obtained by writing to the Free Software Foundation, Inc.,
580 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
581
582
583
584 10.7. LGPL with Libtool exception clause
585
586 Finally, not only is Libltdl is LGPLed, but it is routinely
587 redistributed inside projects that use it, so its sources need to use
588 the following license text citing the LGPL along with Libtool's special
589 exception clause:
590
591 Copyright (C) <year list> Free Software Foundation, Inc.
592 Written by <author>, <year>
593
594 NOTE: The canonical source of this file is maintained with the
595 GNU Libtool package. Report bugs to bug-libtool@gnu.org.
596
597 GNU Libltdl is free software; you can redistribute it and/or
598 modify it under the terms of the GNU Lesser General Public
599 License as published by the Free Software Foundation; either
600 version 2 of the License, or (at your option) any later version.
601
602 As a special exception to the GNU Lesser General Public License,
603 if you distribute this file as part of a program or library that
604 is built using GNU Libtool, you may include this file under the
605 same distribution terms that you use for the rest of that program.
606
607 GNU Libltdl is distributed in the hope that it will be useful,
608 but WITHOUT ANY WARRANTY; without even the implied warranty of
609 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
610 GNU Lesser General Public License for more details.
611
612 You should have received a copy of the GNU Lesser General Public
613 License along with GNU Libltdl; see the file COPYING.LIB. If not, a
614 copy can be downloaded from http://www.gnu.org/licenses/lgpl.html,
615 or obtained by writing to the Free Software Foundation, Inc.,
616 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
617
618
619 11. Release Procedure
620 =====================
621
622 * If you are a libtool maintainer, but have not yet registered your
623 gpg public key and (preferred) email address with the FSF, send an
624 email, preferably GPG-signed, to <ftp-upload@gnu.org> that includes
625 the following:
626
627 (a) name of package(s) that you are the maintainer for, and your
628 preferred email address.
629
630 (b) an ASCII armored copy of your GnuPG key, as an attachment.
631 ("gpg --export -a YOUR_KEY_ID > mykey.asc" should give you
632 this.)
633
634 When you have received acknowledgement of your message, the proper GPG
635 keys will be registered on ftp-upload.gnu.org and only then will you be
636 authorized to upload files to the FSF ftp machines.
637
638 * If you do not have access to the mailing list administrative interface,
639 approach the list owners for the password. Be sure to check the lists
640 (esp. bug-libtool) for outstanding bug reports also in the list of
641 pending moderation requests.
642
643 * Make sure you have wget installed.
644
645 * Make sure you have a copy of xdelta installed, and a copy of the previous
646 release tarball in the build directory.
647
648 * Make sure your locale is sane, e.g. by exporting LC_ALL=C.
649
650 * Double check that serial number updates in public m4 files weren't forgotten
651 since last release (they should be updated in CVS along with commits that
652 require it so that users can work with CVS snapshots).
653
654 * Update the LTDL_VERSION_INFO in libltdl/Makefile.inc for changes since
655 the last release.
656
657 * Update the version number in configure.ac and libltdl/configure.ac.
658 See http://www.gnu.org/software/libtool/contribute.html for details of
659 the numbering scheme.
660
661 * Update NEWS, ChangeLog.
662
663 * Run ./bootstrap.
664
665 * Have some tea. If you are running on less than 3.6GHz CPU, order
666 a pizza too ;-)
667
668 * Run ./configure (or create a build directory first and run configure
669 from there, if you want to keep the build tree separate).
670
671 * Run `make -fMakefile.maint fetch' (or `make -f../Makefile.maint fetch'
672 if you are running from a VPATH build directory, where `../' is the
673 relative path to the directory with `configure' in it), which will
674 fetch new versions of the files that are maintained outside of
675 libtool.
676
677 * Run `make distcheck' and `make distcheck
678 DISTCHECK_CONFIGURE_FLAGS=--disable-ltdl-install'. Try a distcheck
679 with --program-prefix=g. If there are any problems, fix them and
680 start again.
681
682 * Run ./commit from the source tree.
683
684 * Run `make -fMakefile.maint cvs-dist' (or `make -f../Makefile.maint
685 cvs-dist' if you are running from a VPATH build directory, where `../'
686 is the relative path to the directory with `configure' in it), which
687 will build a release tarball (with `make distcheck'), tag the tree
688 with release-$(VERSION) and generate the gpg signature files.
689
690 * Run 'make -f[../]Makefile.maint deltas' (pass
691 LASTRELEASE=maj.min[.mic[alpha]] if needed) to create both diff and
692 xdelta files between the previous release tarball and the new with
693 detached gpg signature files and clear signed directive files.
694
695 * Upload release tarball, diff file and xdelta file, plus their associated
696 detached gpg signature files and clear signed directive files to
697 ftp-upload.gnu.org. If the upload is destined for ftp.gnu.org, then the
698 files should be placed in the /incoming/ftp directory. If the upload is
699 an alpha release destined for alpha.gnu.org, then the files should be
700 placed in the /incoming/alpha directory.
701
702 * Send announcement to libtool@gnu.org and autotools-announce@gnu.org,
703 if not an alpha send to info-gnu@gnu.org as well.
704
705 * Update version number in configure.ac and libltdl/configure.ac to next
706 alpha number. See http://www.gnu.org/software/libtool/contribute.html
707 for details of the numbering scheme.
708
709 * Update NEWS, ChangeLog.
710
711 * Run ./commit.
712
713 * Update the webpages, libtool.html will need to indicate the latest
714 release number and the news page should get a HTMLified copy of your
715 release announcement.
716
717 * If not an alpha, replace manual.html with the new one
718 (generate with `make -f[../]Makefile.maint web-manual').
719
720
721
722 12. Alpha release note template
723 ===============================
724
725 To: libtool@gnu.org, autotools-announce@gnu.org
726 Subject: GNU Libtool @VERSION@ released (alpha release).
727
728 The Libtool Team is pleased to announce alpha release @VERSION@ of GNU
729 Libtool.
730
731 GNU Libtool hides the complexity of using shared libraries behind a
732 consistent, portable interface. GNU Libtool ships with GNU libltdl,
733 which hides the complexity of loading dynamic runtime libraries
734 (modules) behind a consistent, portable interface.
735
736 Here are the compressed sources:
737
738 ftp://alpha.gnu.org/gnu/libtool/libtool-@VERSION@.tar.gz
739 ftp://alpha.gnu.org/gnu/libtool/libtool-@VERSION@.tar.bz2
740
741 Here are the xdeltas and diffs against libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@:
742
743 ftp://alpha.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz
744 ftp://alpha.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta
745
746 Here are the gpg detached signatures:
747
748 ftp://alpha.gnu.org/gnu/libtool/libtool-@VERSION@.tar.gz.sig
749 ftp://alpha.gnu.org/gnu/libtool/libtool-@VERSION@.tar.bz2.sig
750 ftp://alpha.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz.sig
751 ftp://alpha.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta.sig
752
753 You should download the signature named after any tarball you download,
754 and then verify its integrity with, for example:
755
756 gpg --verify libtool-@VERSION@.tar.gz.sig
757
758 Here are the MD5 and SHA1 checksums:
759
760 @MD5SUM@ libtool-@VERSION@.tar.gz
761 @MD5SUM@ libtool-@VERSION@.tar.bz2
762 @MD5SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz
763 @MD5SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta
764 @SHA1SUM@ libtool-@VERSION@.tar.gz
765 @SHA1SUM@ libtool-@VERSION@.tar.bz2
766 @SHA1SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz
767 @SHA1SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta
768
769 This release has @SUMMARY_OF_IMPROVEMENTS_SINCE_LAST_RELEASE_ON_THIS_BRANCH@.
770
771 This release was bootstrapped with @BOOTSTRAP_TOOLS_WITH_VERSIONS@,
772 but is useable with @COMPATIBLE_AUTOTOOL_VERSIONS@ in your own
773 projects.
774
775 Alternatively, you can fetch the unbootstrapped source code from
776 anonymous cvs by using the following command:
777
778 $ cvs -z3 -d :pserver:anonymous@cvs.sv.gnu.org:/sources/libtool \
779 co -r @CVS_RELEASE_TAG@ libtool
780
781 You will then need to have recent (possibly as yet unreleased) versions
782 of Automake and Autoconf installed to bootstrap the checked out
783 sources yourself.
784
785 New in @VERSION@: @RELEASE_DATE@
786
787 @EXCERPT_FROM_NEWS_FILE@
788
789 Please report bugs to <bug-libtool@gnu.org>, along with the verbose
790 output of any failed test groups, and the output from `./libtool --config.'
791 The README file explains how to capture the verbose test output.
792
793
794
795 13. Full release note template
796 ==============================
797
798 To: info-gnu@gnu.org
799 Cc: libtool@gnu.org, autotools-announce@gnu.org
800 Subject: GNU Libtool @VERSION@ released.
801
802 The Libtool Team is pleased to announce the release of GNU Libtool
803 @VERSION@.
804
805 GNU Libtool hides the complexity of using shared libraries behind a
806 consistent, portable interface. GNU Libtool ships with GNU libltdl,
807 which hides the complexity of loading dynamic runtime libraries
808 (modules) behind a consistent, portable interface.
809
810 This release has @SUMMARY_OF_IMPROVEMENTS_SINCE_LAST_RELEASE_ON_THIS_BRANCH@.
811
812 New in @VERSION@: @RELEASE_DATE@
813
814 @EXCERPT_FROM_NEWS_FILE@
815
816 libtool-@VERSION@ is available now from ftp.gnu.org, along with
817 diffs and xdeltas against libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@
818 that are also available from ftp.gnu.org. Please
819 use a mirror to reduce stress on the main gnu machine:
820
821 http://www.gnu.org/order/ftp.html
822
823 Here are the compressed sources:
824
825 ftp://ftp.gnu.org/gnu/libtool/libtool-@VERSION@.tar.gz
826 ftp://ftp.gnu.org/gnu/libtool/libtool-@VERSION@.tar.bz2
827
828 Here are the xdeltas and diffs against libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@:
829
830 ftp://ftp.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz
831 ftp://ftp.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta
832
833 Here are the gpg detached signatures:
834
835 ftp://ftp.gnu.org/gnu/libtool/libtool-@VERSION@.tar.gz.sig
836 ftp://ftp.gnu.org/gnu/libtool/libtool-@VERSION@.tar.bz2.sig
837 ftp://ftp.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz.sig
838 ftp://ftp.gnu.org/gnu/libtool/libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta.sig
839
840 You should download the signature named after any tarball you download,
841 and then verify its integrity with, for example:
842
843 gpg --verify libtool-@VERSION@.tar.gz.sig
844
845 Here are the MD5 and SHA1 checksums:
846
847 @MD5SUM@ libtool-@VERSION@.tar.gz
848 @MD5SUM@ libtool-@VERSION@.tar.bz2
849 @MD5SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz
850 @MD5SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta
851 @SHA1SUM@ libtool-@VERSION@.tar.gz
852 @SHA1SUM@ libtool-@VERSION@.tar.bz2
853 @SHA1SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.diff.gz
854 @SHA1SUM@ libtool-@PREV_RELEASE_VERSION_ON_THIS_BRANCH@-@VERSION@.xdelta
855
856 This release was bootstrapped with @BOOTSTRAP_TOOLS_WITH_VERSIONS@,
857 but is useable with @COMPATIBLE_AUTOTOOL_VERSIONS@ in your own
858 projects.
859
860 Alternatively, you can fetch the unbootstrapped source code from
861 anonymous cvs by using the following command (just hit return when
862 you are prompted for the password):
863
864 $ cvs -z3 -d :pserver:anonymous@cvs.sv.gnu.org:/sources/libtool \
865 co -r @CVS_RELEASE_TAG@ libtool
866
867 You will then need to have the latest release versions of Automake
868 (@AUTOMAKE_VERSION@) and Autoconf (@AUTOCONF_VERSION@) installed to
869 bootstrap the checked out sources yourself.
870
871 Please report bugs to <bug-libtool@gnu.org>, along with the verbose
872 output of any failed test groups, and the output from `./libtool --config.'
873 The README file explains how to capture the verbose test output.
874
875
876 --
877 Copyright (C) 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
878 Written by Gary V. Vaughan, 2004
879
880 This file is part of GNU Libtool. Report bugs to bug-libtool@gnu.org.
881
882 GNU Libtool is free software; you can redistribute it and/or
883 modify it under the terms of the GNU General Public License as
884 published by the Free Software Foundation; either version 2
885 of the License, or (at your option) any later version.
886
887 GNU Libtool is distributed in the hope that it will be useful,
888 but WITHOUT ANY WARRANTY; without even the implied warranty of
889 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
890 GNU General Public License for more details.
891
892 You should have received a copy of the GNU General Public License
893 along with GNU Libtool; see the file COPYING. If not, a copyi
894 can be downloaded from http://www.gnu.org/licenses/gpl.html,
895 or obtained by writing to the Free Software Foundation, Inc.,
896 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
897
898 Local Variables:
899 mode: text
900 fill-column: 72
901 End:
902 vim:tw=72

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