39 |
doc/ |
doc/ |
40 |
+ fdl.texi |
+ fdl.texi |
41 |
libltdl/ |
libltdl/ |
42 |
+ COPYING.LESSER |
+ COPYING.LIB |
|
+ config.guess |
|
|
+ config.sub |
|
|
+ install-sh |
|
|
+ missing |
|
43 |
The ones that are important for a release can be udated with, |
The ones that are important for a release can be udated with, |
44 |
`make -fMakefile.maint fetch' (or `make -f../Makefile.maint fetch' |
`make -fMakefile.maint fetch' (or `make -f../Makefile.maint fetch' |
45 |
if you are running from a VPATH build directory, where `../' is the |
if you are running from a VPATH build directory, where `../' is the |
48 |
* Changes other than bug fixes must be mentioned in NEWS |
* Changes other than bug fixes must be mentioned in NEWS |
49 |
|
|
50 |
|
|
51 |
2. Test Suite |
3. Test Suite |
52 |
============= |
============= |
53 |
|
|
54 |
* 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 |
55 |
many compilers and linkers you can. |
many compilers and linkers you can. |
56 |
|
|
57 |
|
|
58 |
3. Naming |
4. Naming |
59 |
========= |
========= |
60 |
|
|
61 |
* We've adopted the convention that exported Autoconf macros should be |
* We've adopted the convention that exported Autoconf macros should be |
71 |
with the `_lt_' macro namespace). |
with the `_lt_' macro namespace). |
72 |
|
|
73 |
|
|
74 |
4. Editing `.am' Files |
5. Editing 'ChangeLog' |
75 |
|
====================== |
76 |
|
|
77 |
|
* When in doubt, check that emacs can syntax-color properly in |
78 |
|
change-log-mode. And preferably use emacs 'C-x 4 a' |
79 |
|
(add-change-log-entry-other-window) to open ChangeLog with an |
80 |
|
appropriate new template. |
81 |
|
|
82 |
|
* If this change is by a different author, or on a different date to the |
83 |
|
last entry start a new entry at the top of the file with the format |
84 |
|
(note two spaces between each field): |
85 |
|
|
86 |
|
yyyy-mm-dd Name of Author <email@address> |
87 |
|
|
88 |
|
* If more than one person collaborated on the change, additional |
89 |
|
authors can be listed on subsequent lines, thus: |
90 |
|
|
91 |
|
yyyy-mm-dd Name of Main Author <email@address>, |
92 |
|
Name of Contributor <another@email.address> |
93 |
|
|
94 |
|
* Where a change author did not supply a copyright assignment, but the |
95 |
|
changes they submitted were sufficiently trivial to commit in any case |
96 |
|
(see the GCS for guidelines on this), then flag this against their |
97 |
|
name in the header, thus: |
98 |
|
|
99 |
|
yyyy-mm-dd Name of Author <email@address> (tiny change) |
100 |
|
|
101 |
|
* In ChangeLog.2004 and earlier, 'Name of Author' was sometimes the name |
102 |
|
of the author of the ChangeLog when the person who made the change |
103 |
|
being documented didn't supply one. In that case separated from |
104 |
|
the previous field by a blank line and indented by 1 tab (note, only |
105 |
|
1 space between fields here) you will see: |
106 |
|
|
107 |
|
From Author of Actual Change <email@address>: |
108 |
|
|
109 |
|
As of now, don't do that anymore, since the GNU Coding Standards say |
110 |
|
that the author of the change must be credited in the main entry |
111 |
|
header for legal purposes. |
112 |
|
|
113 |
|
* Preferably the next part should be a description of the overall |
114 |
|
purpose of the change, separated from the header by a blank line, |
115 |
|
indented by 1 tab, and filled at column 72. The last character of the |
116 |
|
description should be a colon, :. |
117 |
|
|
118 |
|
* Changes to each file come next. Each new file starts on a new line, |
119 |
|
indented by 1 tab and starting with an asterisk and a space. Multiple |
120 |
|
files can be listed here relative to $top_srcdir, and comma separated. |
121 |
|
Names of functions (or sections as appropriate) to which the change |
122 |
|
applies should be named inside parentheses and comma separated. If |
123 |
|
this goes beyond column 72, then parens should be closed and re-opened |
124 |
|
on the next line: |
125 |
|
|
126 |
|
* file, another/file, test/testcases/foo.test (func_foo) |
127 |
|
(func_bar, func_baz): Description of changes. |
128 |
|
|
129 |
|
* If the change does not apply to particular functions (or sections), |
130 |
|
the section list can be omitted: |
131 |
|
|
132 |
|
* file, another/file, test/testcases/foo.test: General changes. |
133 |
|
|
134 |
|
* If the changes are particular to certain architectures, they should be |
135 |
|
listed after the functions in square brackets: |
136 |
|
|
137 |
|
* file, another/file (func_foo) [linux, solaris]: Description of |
138 |
|
changes. |
139 |
|
|
140 |
|
* Subsequent changes in other files that are related to the same overall |
141 |
|
enhancement or bugfix should be listed concurrently, without blank |
142 |
|
lines. Always start a fresh line for a new file: |
143 |
|
|
144 |
|
* file, another/file (func_foo) [linux, solaris]: Description of |
145 |
|
changes. |
146 |
|
* doc/foo.texi (Invoking Foo): Document. |
147 |
|
* NEWS: Updated. |
148 |
|
|
149 |
|
* If the change is in response to a problem reported by someone other |
150 |
|
than the author, then credit them at the end of the description with: |
151 |
|
|
152 |
|
Reported by Reporter Name <email@address>. |
153 |
|
|
154 |
|
* See the GNU Coding Standards document for more details on ChangeLog |
155 |
|
formatting. |
156 |
|
|
157 |
|
|
158 |
|
2005-01-08 Ralf Wildenhues <Ralf.Wildenhues@gmx.de> (tiny change), |
159 |
|
Peter O'Gorman <peter@pogma.com> |
160 |
|
|
161 |
|
This is the overall description of the purpose of this change |
162 |
|
and any useful background for a model ChangeLog entry: |
163 |
|
|
164 |
|
* HACKING: Updated copyright. This isn't attached to a |
165 |
|
particular section of the file, so it comes first. |
166 |
|
(Editing 'ChangeLog'): New section. This applies to the same |
167 |
|
file, but since it applies to a particular section it starts on |
168 |
|
a new line. |
169 |
|
(Introduction, Maintenance Notes, Test Suite, Naming) |
170 |
|
(Editing '.am' Files): If I had changed all these sections in |
171 |
|
the same way, I can list them like this, being careful to close |
172 |
|
and reopen the parentheses when starting a new line. The colon |
173 |
|
only comes after the last section before this description. |
174 |
|
* NEWS: Updated. |
175 |
|
Reported by Bob Friesenhahn <bfriesen@simple.dallas.tx.us>. |
176 |
|
|
177 |
|
|
178 |
|
6. Editing `.am' Files |
179 |
====================== |
====================== |
180 |
|
|
181 |
* Always use $(...) and not ${...} |
* Always use $(...) and not ${...} |
186 |
|
|
187 |
* Never use basename or dirname. Instead use sed. |
* Never use basename or dirname. Instead use sed. |
188 |
|
|
189 |
* Do not use `cd' within back-quotes, use `$(am__cd)' instead. |
* Do not use `cd' within back-quotes, use `$(lt__cd)' instead. |
190 |
Otherwise the directory name may be printed, depending on CDPATH. |
Otherwise the directory name may be printed, depending on CDPATH. |
191 |
|
|
192 |
* 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 |
193 |
of the loop itself should print each "important" command it runs. |
of the loop itself should print each "important" command it runs. |
194 |
|
|
195 |
|
|
196 |
5. Editing libtoolize.in and ltmain.in |
7. Editing `.m4sh' Files |
197 |
====================================== |
======================== |
198 |
|
|
199 |
* Use shell functions, but be careful not to assume local scope for |
* Use shell functions, but be careful not to assume local scope for |
200 |
variable names. Don't use `return', instead echo the result of a |
variable names. Don't use `return', instead echo the result of a |
201 |
function and call it from within backquotes. |
function and call it from within backquotes. |
202 |
|
|
203 |
6. Abstraction layers in libltdl |
* Function names should be prefixed `func_', the function header should |
204 |
|
look like this: |
205 |
|
|
206 |
|
# func_foo [ OPTIONS ] |
207 |
|
# Description of what func_foo does and returns. |
208 |
|
func_foo () |
209 |
|
{ |
210 |
|
$opt_debug |
211 |
|
# contents of func_foo ... |
212 |
|
} |
213 |
|
|
214 |
|
The `$opt_debug' is used to enable shell tracing (Korn shells reset |
215 |
|
this on function entry). |
216 |
|
|
217 |
|
* For functions that are called frequently, if you need to return a |
218 |
|
value, don't cause unneccessary forking of the shell using echo as |
219 |
|
described above; instead set the return value in a variable named |
220 |
|
after the called function with a suffix of `_result'. For example |
221 |
|
the function `func_quote_for_eval' stores its return value in the |
222 |
|
variable `$func_quote_for_eval_result'. |
223 |
|
|
224 |
|
* Although sh-indentation is set to 2 (by the `Local Variables:' block |
225 |
|
at the end of .m4sh files), the left margin of the body of shell |
226 |
|
functions should begin indented by 4 spaces. |
227 |
|
|
228 |
|
|
229 |
|
8. Editing `.m4' Files |
230 |
|
====================== |
231 |
|
|
232 |
|
* Be careful with both `echo' and `$ECHO'. As the latter may be one of |
233 |
|
echo |
234 |
|
print -r |
235 |
|
printf %s\n |
236 |
|
$CONFIG_SHELL $0 --fallback-echo |
237 |
|
it may not have more than one argument, its value may not be eval'ed |
238 |
|
and the argument may not start with a `-'. As a rule of thumb, use |
239 |
|
echo .. for literal (constant) strings without leading |
240 |
|
hyphen and no backslashes within, |
241 |
|
$ECHO ".." for strings without leading hyphen, |
242 |
|
$ECHO "X.." | $Xsed otherwise. |
243 |
|
|
244 |
|
|
245 |
|
9. Abstraction layers in libltdl |
246 |
================================ |
================================ |
247 |
|
|
248 |
* The libltdl API uses a layered approach to differentiate internal and |
* The libltdl API uses a layered approach to differentiate internal and |
326 |
lt__private.h |
lt__private.h |
327 |
|
|
328 |
|
|
329 |
7. Release Procedure |
10. Release Procedure |
330 |
==================== |
==================== |
331 |
|
|
332 |
* If you are a libtool maintainer, but have not yet registered your |
* If you are a libtool maintainer, but have not yet registered your |
345 |
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 |
346 |
authorized to upload files to the FSF ftp machines. |
authorized to upload files to the FSF ftp machines. |
347 |
|
|
348 |
|
* If you do not have access to the mailing list administrative interface, |
349 |
|
approach the list owners for the password. Be sure to check the lists |
350 |
|
(esp. bug-libtool) for outstanding bug reports also in the list of |
351 |
|
pending moderation requests. |
352 |
|
|
353 |
* Make sure you have wget installed. |
* Make sure you have wget installed. |
354 |
|
|
355 |
* 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 |
356 |
release tarball in the build directory. |
release tarball in the build directory. |
357 |
|
|
358 |
|
* Make sure your locale is sane, e.g. by exporting LC_ALL=C. |
359 |
|
|
360 |
|
* Double check that serial number updates in public m4 files weren't forgotten |
361 |
|
since last release (they should be updated in CVS along with commits that |
362 |
|
require it so that users can work with CVS snapshots). |
363 |
|
|
364 |
|
* Double check that libltdl version number updates weren't forgotten since last |
365 |
|
release (they should be updated in CVS along with commits that require it so |
366 |
|
that users can work with CVS snapshots). |
367 |
|
|
368 |
* Update the version number in configure.ac. |
* Update the version number in configure.ac. |
369 |
See http://www.gnu.org/software/libtool/contribute.html for details of |
See http://www.gnu.org/software/libtool/contribute.html for details of |
370 |
the numbering scheme. |
the numbering scheme. |
385 |
fetch new versions of the files that are maintained outside of |
fetch new versions of the files that are maintained outside of |
386 |
libtool. |
libtool. |
387 |
|
|
388 |
* Run `make distcheck'. If there are any problems, fix them and start |
* Run `make distcheck' and `make distcheck |
389 |
again. |
DISTCHECK_CONFIGURE_FLAGS=--disable-ltdl-install'. If there are any |
390 |
|
problems, fix them and start again. |
391 |
|
|
392 |
* Run ./commit from the source tree. |
* Run ./commit from the source tree. |
393 |
|
|
398 |
with release-$(VERSION) and generate the gpg signature files. |
with release-$(VERSION) and generate the gpg signature files. |
399 |
|
|
400 |
* Run 'make -f[../]Makefile.maint deltas' (pass |
* Run 'make -f[../]Makefile.maint deltas' (pass |
401 |
LASTRELEASE=min.maj[.mic[alpha]] if needed) to create both diff and |
LASTRELEASE=maj.min[.mic[alpha]] if needed) to create both diff and |
402 |
xdelta files between the previous release tarball and the new with |
xdelta files between the previous release tarball and the new with |
403 |
detached gpg signature files and clear signed directive files. |
detached gpg signature files and clear signed directive files. |
404 |
|
|
429 |
|
|
430 |
|
|
431 |
|
|
432 |
7. Alpha release note template |
11. Alpha release note template |
433 |
============================== |
=============================== |
434 |
|
|
435 |
To: libtool@gnu.org, autotools-announce@gnu.org |
To: libtool@gnu.org, autotools-announce@gnu.org |
436 |
Subject: GNU Libtool @VERSION@ released (alpha release). |
Subject: GNU Libtool @VERSION@ released (alpha release). |
463 |
You should download the signature named after any tarball you download, |
You should download the signature named after any tarball you download, |
464 |
and then verify its integrity with, for example: |
and then verify its integrity with, for example: |
465 |
|
|
466 |
gpg --verify libtool-@VERSION.tar.gz. |
gpg --verify libtool-@VERSION.tar.gz.sig |
467 |
|
|
468 |
Here are the MD5 and SHA1 checksums: |
Here are the MD5 and SHA1 checksums: |
469 |
|
|
502 |
|
|
503 |
|
|
504 |
|
|
505 |
8. Full release note template |
12. Full release note template |
506 |
============================= |
============================== |
507 |
|
|
508 |
To: info-gnu@gnu.org |
To: info-gnu@gnu.org |
509 |
Cc: libtool@gnu.org, autotools-announce@gnu.org |
Cc: libtool@gnu.org, autotools-announce@gnu.org |
514 |
|
|
515 |
GNU Libtool hides the complexity of using shared libraries behind a |
GNU Libtool hides the complexity of using shared libraries behind a |
516 |
consistent, portable interface. GNU Libtool ships with GNU libltdl, |
consistent, portable interface. GNU Libtool ships with GNU libltdl, |
517 |
which hides the comlexity of loading dynamic runtime libraries |
which hides the complexity of loading dynamic runtime libraries |
518 |
(modules) behind a consistent, portable interface. |
(modules) behind a consistent, portable interface. |
519 |
|
|
520 |
This release has @SUMMARY_OF_IMPROVEMENTS_SINCE_LAST_RELEASE_ON_THIS_BRANCH@. |
This release has @SUMMARY_OF_IMPROVEMENTS_SINCE_LAST_RELEASE_ON_THIS_BRANCH@. |
550 |
You should download the signature named after any tarball you download, |
You should download the signature named after any tarball you download, |
551 |
and then verify its integrity with, for example: |
and then verify its integrity with, for example: |
552 |
|
|
553 |
gpg --verify libtool-@VERSION.tar.gz. |
gpg --verify libtool-@VERSION.tar.gz.sig |
554 |
|
|
555 |
Here are the MD5 and SHA1 checksums: |
Here are the MD5 and SHA1 checksums: |
556 |
|
|
584 |
|
|
585 |
|
|
586 |
-- |
-- |
587 |
Copyright (C) 2004 Free Software Foundation, Inc. |
Copyright (C) 2004, 2005 Free Software Foundation, Inc. |
588 |
|
|
589 |
The canonical source of this file is maintained with the |
The canonical source of this file is maintained with the |
590 |
GNU Libtool package. Report bugs to bug-libtool@gnu.org. |
GNU Libtool package. Report bugs to bug-libtool@gnu.org. |
606 |
|
|
607 |
You should have received a copy of the GNU General Public License |
You should have received a copy of the GNU General Public License |
608 |
along with GNU Libtool; if not, write to the Free Software |
along with GNU Libtool; if not, write to the Free Software |
609 |
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA |
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA |
610 |
02111-1307 USA |
02110-1301 USA |
611 |
|
|
612 |
|
|
613 |
Local Variables: |
Local Variables: |