TODO

   1 Top priorities:
   2 * Use info_TEXINFOS
   3 * Figure out how to handle MANS:
   4   * use man_MANS?  Or man1_MANS, man2_MANS, etc?
   5   * François wants man pages not to be installed by default.
   6     in this case an additional "install-man" target would exist
   7 * Must rewrite am_install_var.  Should break into multiple functions.
   8   This will allow the callers to be a little smarter.
   9 * Use "$o" instead of "$(kr)o".  This might be better if MS-DOS is ever
  10   supported.
  11
  12 * am_error should use printf-style arguments (for eventual gettext scheme)
  13
  14 Add AM_OPTIONS macro.  Can include:
  15 "gnits", "gnu", "normal", "ansi2kr", "installman"
  16
  17 uninstall and pkg-dirs should rm -rf the dir.
  18
  19 In general most .am files should be merged into automake.  For
  20 instance all the "clean" targets could be merged by keeping lists of
  21 things to be removed.  This would be a lot nicer looking.  Note that
  22 the install targets probably should not be merged; it is sometimes
  23 useful to only install a small part.
  24
  25 Clean up the output:
  26 * Order rules sensibly
  27 * Ensure every line has a purpose.  Omit unused stuff
  28 * Eliminate extraneous rules when possible (eg 'install-am' stuff)
  29 * Make sure vertical spacing is correct
  30 * pretty-print targets
  31 * regularize how backslash-newline is done.  Just one space between text
  32   and backslash should be the rule.  Update makefile-mode to allow this.
  33   (set column to 0, probably)
  34
  35 Need OTHER_SOURCES to hold sources whose objects end up in eg LIBOBJS.
  36 Dependency tracking should work here.  Maybe if it doesn't exist it
  37 should be generated automatically by scanning the directory.  (yes)
  38
  39 "@kr@" is a hack that should be fixed.  And it should be possible to
  40 have ansi2knr in just one place in a package.  Jim Meyering says just
  41 rely on configure to make links as appropriate.  Not sure how I feel
  42 about this.
  43
  44 Consider automatic support for ".y" files.
  45   [ not right now; it is nice to be able to print the number of
  46     expected conflicts, and we can't handle that ]
  47
  48 Write autoconf macro to do all work necessary for automake.  Eg define
  49 PACKAGE, VERSION, etc.
  50
  51 Change glob pattern to look for to '*/Makefile*.am', so that gettext's
  52 po directory can use a Makefile.in.am (and generate Makefile.in.in)
  53
  54 Should 'distclean' remove $(SCRIPTS)?
  55 Should 'maintainer-clean' do "rm -rf .deps"?
  56 Should look for clean-local targets in Makefile.am.
  57
  58 Think about writing a small tool to guess what the local Makefile.am
  59 should look like.
  60
  61 It might be cool to generate .texi dependencies by grepping for
  62 @include.  (If done, it should be done the same way C dependency is
  63 done)
  64
  65 Rename --include-deps to --insert-deps?
  66
  67 It would be good to check some parts of GNU standards.  Already check
  68 for install-sh and mkinstalldirs.  What else is required to be in
  69 package by GNU standards or by automake?
  70 Some things for --strictness=gnits:
  71 * "cd $(foo); something" is an error in a rule.  Should be:
  72   "cd $(foo) && something"
  73 * check for version number in NEWS file.
  74
  75 Maybe it should be possible to disable all GNU-specific things with
  76 --no-gnu? --ignore-standards?  But what?  And why?
  77
  78 Allow ".h" files to appear in blah_SOURCES; just write them out of
  79 existence.  [ This is nixed for now because of the auto-dependency
  80 tracking stuff ]
  81
  82 automake.in: should ".cc" really -> ".${kr}o"?  This doesn't really
  83 seem right, but maybe it is so names can be rewritten uniformly?  Must
  84 check
  85
  86 look in configure.in's AC_OUTPUT command and include those files in
  87 distribution.  Or consider new CONFIGURED_FILES macro that lists files
  88 generated by config.status.
  89
  90 Auto-distribute "ChangeLog.[0-9]+"?
  91
  92 consider auto-including any file that matches "*.in".
  93   [ no: po/Makefile.in shouldn't be included ]
  94
  95 must look at mkid to see how it works (for subdir usage)
  96   [ right now, it doesn't.  i don't see a simple fix right now ]
  97
  98 Internationalize. [ gettext doesn't have the necessary machinery yet ]
  99
 100 write test suite
 101
 102 François says the ordering of files in a distribution should be as follows:
 103 * README
 104 * source files
 105 * derived files
 106 I agree, but I don't see how to implement this yet.
 107
 108 Should COPYING.LIB be distributed?
 109
 110 Look at configure.in to see if NLS support is used.  Then require the
 111 file ABOUT-NLS.  Be sure to write this so that other configure.in
 112 tweaks are easy.
 113
 114 Check all source files to make sure that FSF address is up-to-date.
 115 --gnits or --gnu only.
 116
 117 Merge each -vars.am file with corresponding ".am" file.  Can do this
 118 because of changes to &file_contents.
 119
 120 Looked at a program called 'ezmake', which seems to do something
 121 similar.  The only idea there that is possibly worth stealing is using
 122 globs in definitions.  Also has negations.  Eg in a directory with
 123 files a.c, b.c and c.c, the line:
 124         foo_SOURCES = *.c ~c.c
 125 would be equivalent to:
 126         foo_SOURCES = a.c b.c
 127 Is this worth implementing?
 128
 129 ================================================================
 130
 131 For CONFIG_HEADER,
 132   automatically add its input file to the distribution.
 133
 134 Don't hardcode the name of the configuration header.  Get it from
 135 configure.in (AC_CONFIG_HEADER).
 136
 137 Get the list of Makefiles to create from configure.in AC_OUTPUT
 138 if none are given.
 139         [ right now we look for any Makefile.am's lying around
 140           I think this is better, because it allows use of subdirs
 141           which don't use automake -- eg, stuff from gettext ]
 142
 143 Should libexec programs have the name transform done on them?
 144
 145 Order the output rules sensibly, so FOO_SOURCES and FOO_OBJECTS are
 146 together and rules are in the usual order.
 147
 148 Make the output minimal: only output definitions for variables that
 149 are used.
 150
 151 Look at dist's jmake for ideas.  [what is this?]
 152
 153 Should handle directory hierarchies deeper than 2.  Right now there is
 154 no support for this at all.
 155
 156 ================================================================
 157
 158 Known Bugs:
 159
 160 version.texi handling is broken -- it assumes you only have one .texi
 161 file per directory.
 162    (*) In any case, the UPDATED information would be different for
 163    each .texi file included in a package -- that is my problem.
 164    Now, if no package will ever have more than one .texi file
 165    (in a given directory), I can just stop worrying about it.
 166
 167 If there is ever more than one, we will need to change the name of
 168 'version.texi' to be based on the name of the primary .texi file.
 169 Will have to be careful here not to violate MS-DOS name limits.  Also
 170 will need more than one stamp-vti.
 171
 172 [ actually, we could just number them.  version0.texi, version1.texi,
 173 etc ] [ actually, we can't, because the user could be reasonably
 174 expected to want to make dependencies using the name of the .texi file
 175 ] [ actually, the real reason we can't is because it wouldn't be
 176 obvious what name to include in the primary .texi file.  Duh ]
 177
 178 ================================================================
 179
 180 Document:
 181
 182
 183 Defined variables, their meanings, and their effects:
 184
 185 DEFS           cpp definitions
 186 INCLUDES       -I options to cpp
 187 CPPFLAGS       more cpp flags
 188 CFLAGS         flags to cc
 189 COMPILE        how to compile a C program
 190 LINK           how to link a C program
 191
 192 DIST_SUBDIRS   directories which are copied verbatim into the
 193                distribution.  Used eg for directories holding
 194                only example code (which don't have their own
 195                makefile).  This variable might be a bad idea.
 196
 197 lib_LIBADD      code conditionally included in a library
 198                 This probably needs to be redone anyway.
 199
 200 AM_TEXINFOS     override form
 201 SUFFIXES        additional suffixes
 202
 203 Document customary ordering of Makefile.am.  From Franc,ois.
 204
 205 Must document BUILT_SOURCES variable.  See depend.am.
 206
 207 ================================================================
 208
 209 Libraries:
 210
 211 X Need a way to specify library should be installed
 212 * Should support standalone library along with subdir library in same
 213   Makefile.am.  Maybe: turn off "standalone" mode if library's Makefile.am
 214   is not only one specd?
 215 X Need a way to install library header files.
 216 * Need a way to handle shared libraries.
 217   It would be really interesting to be able to easily (as the end-user)
 218   make many different versions of the library: shared, static, profiling,
 219   debug, optimized...
 220   How does Perl handle this?
 221 X Must ranlib libraries after installing
 222
 223 Some examples to keep in mind while doing this:
 224 * readline
 225 * kpathsea
 226
 227 ================================================================
 228
 229 Have a program that generates a Makefile on stdout, passes it through
 230 a "config.status"-style filter, and thence into make.  Why bother,
 231 other than the gee-whiz factor?
 232
 233 Would it be useful to integrate in some way with the Debian package
 234 building utility?  Must check.