2 * Fix up how 'clean' interacts with new naming scheme.
3 * am_error should use printf-style arguments (for eventual gettext scheme)
5 uninstall and pkg-dirs should rm -rf the dir.
9 * Ensure every line has a purpose. Omit unused stuff
10 * Eliminate extraneous rules when possible (eg 'install-am' stuff)
11 * Make sure vertical spacing is correct
12 * pretty-print targets, rules, etc.
14 Need OTHER_SOURCES to hold sources whose objects end up in eg LIBOBJS.
15 Dependency tracking should work here.
17 "@kr@" is a hack that should be fixed. And it should be possible to
18 have ansi2knr in just one place in a package.
20 Consider automatic support for ".y" files. At the very least arrange
21 to have the corresponding ".c" file be distributed.
23 Implement better rule for copying through comments. Rule should be
24 that if comment immediately precedes rule or variable definition, then
25 comment should be put there. Else what happens now is ok.
27 install-info doesn't have to look in build directory for info files;
28 just don't support this mode.
30 Write autoconf macro to do all work necessary for automake. Eg define
31 PACKAGE, VERSION, etc.
33 Change glob pattern to look for to '*/Makefile*.am', so that gettext's
34 po directory can use a Makefile.in.am (and generate Makefile.in.in)
36 Should 'distclean' remove $(SCRIPTS)?
37 Should 'maintainer-clean' do "rm -rf .deps"?
38 Should look for clean-local targets in Makefile.am.
40 Think about writing a small tool to guess what the local Makefile.am
43 Prettyprint macro definitions, eg:
44 DIST_COMMON = Makefile.in Makefile.am \
47 It might be cool to generate .texi dependencies by grepping for
48 @include. (If done, it should be done the same way C dependency is
51 Rename --include-deps to --insert-deps?
53 Merge common parts of "dist" targets into dist-local.
55 It would be good to check some parts of GNU standards. Already check
56 for install-sh and mkinstalldirs. What else is required to be in
57 package by GNU standards or by automake?
58 Some things for --strictness=gnits:
59 * "cd $(foo); something" is an error in a rule. Should be:
60 "cd $(foo) && something"
62 Maybe it should be possible to disable all GNU-specific things with
63 --no-gnu? --ignore-standards? But what? And why?
65 Allow ".h" files to appear in blah_SOURCES; just write them out of
66 existence. [ This is nixed for now because of the auto-dependency
69 automake.in: should ".cc" really -> ".${kr}o"? This doesn't really
70 seem right, but maybe it is so names can be rewritten uniformly? Must
73 look in configure.in's AC_OUTPUT command and include those files in
74 distribution. Or consider new CONFIGURED_FILES macro that lists files
75 generated by config.status.
77 Auto-distribute "ChangeLog.[0-9]+"?
79 consider auto-including any file that matches "*.in".
80 [ no: po/Makefile.in shouldn't be included ]
82 must look at mkid to see how it works (for subdir usage)
83 [ right now, it doesn't. i don't see a simple fix right now ]
85 Internationalize. [ gettext doesn't have the necessary machinery yet ]
87 ================================================================
90 automatically add its input file to the distribution.
92 Don't hardcode the name of the configuration header. Get it from
93 configure.in (AC_CONFIG_HEADER).
95 Get the list of Makefiles to create from configure.in AC_OUTPUT
97 [ right now we look for any Makefile.am's lying around
98 I think this is better, because it allows use of subdirs
99 which don't use automake -- eg, stuff from gettext ]
101 Should libexec programs have the name transform done on them?
103 Order the output rules sensibly, so FOO_SOURCES and FOO_OBJECTS are
104 together and rules are in the usual order.
106 Make the output minimal: only output definitions for variables that
109 Look at dist's jmake for ideas. [what is this?]
111 Should handle directory hierarchies deeper than 2. Right now there is
112 no support for this at all.
114 ================================================================
118 version.texi handling is broken -- it assumes you only have one .texi
120 (*) In any case, the UPDATED information would be different for
121 each .texi file included in a package -- that is my problem.
122 Now, if no package will ever have more than one .texi file
123 (in a given directory), I can just stop worrying about it.
125 If there is ever more than one, we will need to change the name of
126 'version.texi' to be based on the name of the primary .texi file.
127 Will have to be careful here not to violate MS-DOS name limits. Also
128 will need more than one stamp-vti.
130 [ actually, we could just number them. version0.texi, version1.texi,
131 etc ] [ actually, we can't, because the user could be reasonably
132 expected to want to make dependencies using the name of the .texi file
135 ================================================================
140 Defined variables, their meanings, and their effects:
143 INCLUDES -I options to cpp
144 CPPFLAGS more cpp flags
146 COMPILE how to compile a C program
147 LINK how to link a C program
149 DIST_SUBDIRS directories which are copied verbatim into the
150 distribution. Used eg for directories holding
151 only example code (which don't have their own
152 makefile). This variable might be a bad idea.
154 lib_LIBADD code conditionally included in a library
155 This probably needs to be redone anyway.
157 AM_TEXINFOS override form
158 SUFFIXES additional suffixes
160 Document customary ordering of Makefile.am. From Franc,ois.
162 Automake assumes SCRIPTS are built from something else. They are
163 removed during 'make clean'. Beware.
165 ================================================================
169 X Need a way to specify library should be installed
170 * Should support standalone library along with subdir library in same
171 Makefile.am. Maybe: turn off "standalone" mode if library's Makefile.am
172 is not only one specd?
173 X Need a way to install library header files.
174 * Need a way to handle shared libraries.
175 It would be really interesting to be able to easily (as the end-user)
176 make many different versions of the library: shared, static, profiling,
178 X Must ranlib libraries after installing
180 Some examples to keep in mind while doing this:
184 ================================================================
186 Have a program that generates a Makefile on stdout, passes it through
187 a "config.status" style filter, and thence into make. Why bother,
188 other than the gee-whiz factor?
190 Would it be useful to integrate in some way with the Debian package
191 building utility? Must check.