TODO

   1 Top priorities:
   2 * Implement new `where_HOW' scheme.
   3 * Handle installable libraries and headers
   4
   5 Some known problems:
   6 * clean targets not very well tested
   7
   8 Should 'distclean' remove $(SCRIPTS)?
   9 Should 'maintainer-clean' do "rm -rf .deps"?
  10 Should look for clean-local targets in Makefile.am.
  11
  12 Consider a --install-missing option to install missing files such as
  13 mdate-sh, texinfo.tex, etc.
  14
  15 Think about writing a small tool to guess what the local Makefile.am
  16 should look like.
  17
  18 Prettyprint macro definitions, eg:
  19         DIST_COMMON = Makefile.in Makefile.am \
  20         foo bar baz
  21
  22 It might be cool to generate .texi dependencies by grepping for
  23 @include.  (If done, it should be done the same way C dependency is
  24 done)
  25
  26 Rename --include-deps to --insert-deps?
  27
  28 Merge common parts of "dist" targets into dist-local.
  29
  30 It would be good to check some parts of GNU standards.  Already check
  31 for install-sh and mkinstalldirs.  What else is required to be in
  32 package by GNU standards or by automake?
  33
  34 Maybe it should be possible to disable all GNU-specific things with
  35 --no-gnu? --ignore-standards?  But what?  And why?
  36
  37 Allow ".h" files to appear in blah_SOURCES; just write them out of
  38 existence.  [ This is nixed for now because of the auto-dependency
  39 tracking stuff ]
  40
  41 automake.in: should ".cc" really -> ".${kr}o"?  This doesn't really
  42 seem right, but maybe it is so names can be rewritten uniformly?  Must
  43 check
  44
  45 look in configure.in's AC_OUTPUT command and include those files in
  46 distribution.
  47
  48 Auto-distribute "ChangeLog.[0-9]+"?
  49
  50 consider auto-including any file that matches "*.in".
  51   [ no: po/Makefile.in shouldn't be included ]
  52
  53 must look at mkid to see how it works (for subdir usage)
  54   [ right now, it doesn't.  i don't see a simple fix right now ]
  55
  56 Internationalize. [ gettext doesn't have the necessary machinery yet ]
  57
  58 ================================================================
  59
  60 For CONFIG_HEADER,
  61   automatically add its input file to the distribution.
  62
  63 Don't hardcode the name of the configuration header.  Get it from
  64 configure.in (AC_CONFIG_HEADER).
  65
  66 Get the list of Makefiles to create from configure.in AC_OUTPUT
  67 if none are given.
  68         [ right now we look for any Makefile.am's lying around
  69           I think this is better, because it allows use of subdirs
  70           which don't use automake -- eg, stuff from gettext ]
  71
  72 Should libexec programs have the name transform done on them?
  73
  74 Order the output rules sensibly, so FOO_SOURCES and FOO_OBJECTS are
  75 together and rules are in the usual order.
  76
  77 Make the output minimal: only output definitions for variables that
  78 are used.
  79
  80 Look at dist's jmake for ideas.  [what is this?]
  81
  82 Should handle directory hierarchies deeper than 2.  Right now there is
  83 no support for this at all.
  84
  85 ================================================================
  86
  87 Known Bugs:
  88
  89 version.texi handling is broken -- it assumes you only have one .texi
  90 file per directory.
  91    (*) In any case, the UPDATED information would be different for
  92    each .texi file included in a package -- that is my problem.
  93    Now, if no package will ever have more than one .texi file
  94    (in a given directory), I can just stop worrying about it.
  95
  96 If there is ever more than one, we will need to change the name of
  97 'version.texi' to be based on the name of the primary .texi file.
  98 Will have to be careful here not to violate MS-DOS name limits.  Also
  99 will need more than one stamp-vti.
 100
 101 [ actually, we could just number them.  version0.texi, version1.texi,
 102 etc ]
 103
 104 ================================================================
 105
 106 Document:
 107
 108
 109 Defined variables, their meanings, and their effects:
 110
 111 DEFS           cpp definitions
 112 INCLUDES       -I options to cpp
 113 CPPFLAGS       more cpp flags
 114 CFLAGS         flags to cc
 115 COMPILE        how to compile a C program
 116 LINK           how to link a C program
 117
 118 DIST_SUBDIRS   directories which are copied verbatim into the
 119                distribution.  Used eg for directories holding
 120                only example code (which don't have their own
 121                makefile).  This variable might be a bad idea.
 122
 123 MOSTLYCLEANFILES
 124 CLEANFILES
 125 DISTCLEANFILES
 126 MAINTAINERCLEANFILES
 127
 128 lib_LIBADD      code conditionally included in a library
 129                 This probably needs to be redone anyway.
 130
 131 AM_TEXINFOS     override form
 132 SUFFIXES        additional suffixes
 133
 134 Document the AC_PROG_MAKE_SET requirement when SUBDIRS is set.
 135
 136 ================================================================
 137
 138 Libraries:
 139
 140 * Need a way to specify library should be installed
 141 * Should support standalone library along with subdir library in same
 142   Makefile.am.  Maybe: turn off "standalone" mode if library's Makefile.am
 143   is not only one specd?
 144 * Need a way to install library header files.
 145 * Need a way to handle shared libraries.
 146   It would be really interesting to be able to easily (as the end-user)
 147   make many different versions of the library: shared, static, profiling,
 148   debug, optimized...
 149
 150 Some examples to keep in mind while doing this:
 151 * readline
 152 * kpathsea
 153
 154 ================================================================
 155
 156 Have a program that generates a Makefile on stdout, passes it through
 157 a "config.status" style filter, and thence into make.  Why bother,
 158 other than the gee-whiz factor?
 159
 160 Would it be useful to integrate in some way with the Debian package
 161 building utility?  Must check.