1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
|
#+TITLE: Autoconf Archive TODO -*- mode:org;fill-column:79; -*-
* TODO Document our new mailing lists.
* http://lists.nongnu.org/mailman/listinfo/autoconf-archive-announce
This is a low-traffic mailing list used to announce new releases of the
Autoconf Archive.
* http://lists.nongnu.org/mailman/listinfo/autoconf-archive-maintainers
This mailing list can be used to contact the archive maintainers, i.e. to
report problems with the website, the release tarballs, or the
documentation. Patches (git-formatted or otherwise) can be posted here,
too, although the patch tracker is the preferred way of submitting patches
or new macros.
* http://lists.nongnu.org/mailman/listinfo/autoconf-archive-commits
This mailing list distributes an e-mail every time the 'master' branch has
been changed in Git. Other branches, like 'maint', aren't tracked; there is
only a moderate amount of traffic.
* TODO Figure out how to generate the AUTHORS file
The file should contain the people who committed to Git and the people who
are listed in m4 file copyright lines.
* TODO VL_PROG_CC_WARNINGS and AX_CFLAGS_WARN* overlap.
Contact the authors and ask whether they'd like to help re-factor the code.
* TODO Improve submission guide lines on the web site
** New submissions should use an AX_ prefix.
Other prefixes are fine, too, but use of AX_ inside of the Autoconf Archive
is encouraged. The AC_ prefix should definitely be avoided, because it's
reserved for the GNU Autoconf distribution.
** Patch submissions should put the original authors on Cc.
Everyone is welcome to submit patches, bug reports, or suggestions to the
Autoconf Archive. If you do, please add the original authors to carbon-copy
list in the patch tracker. You don't have to, if you don't want to look
their addresses up, but it's considered good practice to give the other
authors a heads up when the macro is being changed.
** If possible, submit patches with Git.
Give a usage example for git format-patch.
If you have an account Savannah, simply request access to the Autoconf
Archive's repository so that you can use git push.
* TODO Recognize cross-links in macro documentation.
Macros often refer to other entries in the archive. The macro2html and
macro2texi scripts should recognize those references and generate appropriate
links in the output.
* TODO Recognize URIs in macro documentation.
Some macros feature http or mailto URIs. The generator scripts should
recognize those and generate appropriate hyperlinks output (where feasible).
* TODO Figure out how to disable sc_file_system check in maint.mk [0/4]
Gnulib wants us to use spelling "file system" and objects when it sees the
name ax_boost_filesystem in autoconf-archive.texi. There ought to be a way to
avoid that error.
Progress: The [[bootstrap.sh]] script disable those checks that don't work well
for this project. In order to get on, though, some meaningful tests were
disable, too. We should re-enable those and fix the macro contents to comply
with those rules:
* [ ] sc_m4_quote_check
* [ ] sc_prohibit_strcmp
* [ ] sc_space_tab
* [ ] sc_useless_cpp_parens
* TODO Link to http://www.flameeyes.eu/autotools-mythbuster/
* TODO Don't use shell globs to configure the list of available macros
The [[configure.ac][configure]] script globs m4/*.m4 to determine the list of available macros.
This mechanism is pretty fragile. Since the exact list is known at the time
we compile the release archive, that information should be inserted in the
script statically. But how?
* TODO Integrate generation of the ChangeLog file into the build system
Currently, [[bootstrap.sh]] generates that file, but this mechanism doesn't
ensure that the file is up-to-date come at the time a release archive is
compiled.
|
