2002-02-23 Per Bothner <per@bothner.com>
[platform/upstream/automake.git] / TODO
diff --git a/TODO b/TODO
index cab6406..d974073 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,3 +1,122 @@
+we can't seem to AC_SUBST(pkgdatadir)
+the version from header-vars overrides
+why is that?
+
+check should depend on all
+  from ben elliston
+
+refactor handle_source_transform and handle_single_transform_list
+we suffer combinatorial explosion here, but there's no need to
+we could transform source variables one at a time
+
+the new YFLAGS code doesn't correctly handle srcdir
+
+allow foo_NAME to rename an object (library or program)
+at build/install time
+
+remove _LTLIBRARIES and just use _LIBRARIES
+then use this for zip/jar as well
+
+consider `sub am_unique_error', which only prints a given error
+message once.  Use eg in lang_c_rewrite for ansi2knr error
+
+for 1.5
+investigate problems with conditionally defined libraries
+
+add an error if the user makefile.am violates our
+   namespace rules
+
+have 'make check' print tests which are skipped
+
+we need a document describing automake from the end user's point of view
+eg describe INSTALL_HEADER there, among other things
+
+* maintainer-clean
+
+Akim:
+> @@ -31,5 +31,9 @@
+>  DISTCLEAN   -test -z "$(DISTCLEANFILES)" || rm -f $(DISTCLEANFILES)
+>
+>  maintainer-clean-generic:
+> +## FIXME: shouldn't we really print these messages before running
+> +## the dependencies?
+> +    @echo "This command is intended for maintainers to use"
+> +    @echo "it deletes files that may require special tools to rebuild."
+>        -rm -f Makefile.in
+
+Tom:
+> I'd like to eventually fix the FIXME comment by having
+> maintainer-clean look like:
+>
+>     maintainer-clean:
+>        @echo ...
+>        $(MAKE) whatever
+>
+> We're left with the question of whether we should repeat them in every
+> subdir.
+
+*
+Alexandre Oliva:
+> Hmm...  Interesting.  It must have been a side effect of the enabling
+> of forced `relink' on GNU/Linux/x86.  Anyway, on platforms that
+> actually require relinking, this problem remains, and I see no way to
+> overcome it other than arranging for automake to install libraries
+> before executables, as you suggest.  This shouldn't be a big problem,
+> anyway.
+>
+> A bigger problem could show up if two libraries in the same directory,
+> one dependent on the other, are installed concurrently.  If relinking
+> is needed for the dependent library, we have a problem.  It appears to
+> me that user will have to live without `make -j install', in this
+> case.
+
+Alex Hornby
+> Here's an Automake patch and changelog entry allow make -j install on
+> such degenerate systems (and Linux with buggy libtool <g>)
+>
+> If you install to locations other that bin_ and lib_ then a larger fix
+> is necessary, but this should fix the 90% case.
+
+* think about how per-object flags should work.  in particular:
+  * how should they be specified?
+    using the object name is confusing when .lo/.obj in use
+    however, the object name provides a nice interaction with
+    per-exe flags
+  * how should they interact with per-executable flags?
+  [ this is probably a feature in search of a problem ]
+
+* cross-compilation support:
+  programs built and used by the build process need to be
+  built for CC_FOR_BUILD
+  introduce a new prefxi for this, e.g. `build_PROGRAMS'
+  [ we can do this in an automatic way I think.
+    unfortunately it isn't that useful until autoconf has support
+    for this sort of thing as well ]
+
+* distcheck should make sure that each file that uses _() is
+  listed in POTFILES.in
+  From Jim Meyering:
+    # Verify that all source files using _() are listed in po/POTFILES.in.
+    po-check:
+           grep -E -v '^(#|$$)' po/POTFILES.in | sort > $@-1
+           grep -E -l '\b_\(' lib/*.c src/*.c | sort > $@-2
+           diff -u $@-1 $@-2
+           rm -f $@-1 $@-2
+
+* one performance enhancement would be to have autoconf write
+  a single file containing all the macro assignments.
+  then read this file via `include'
+  unfortunately this can't be done because of conditionals
+  -- but it could be made to work if we also changed:
+    * automake to rewrite @FOO@ to $(FOO), and
+    * the implementation of conditionals to rely on some new
+      config.status magic
+
+* support prog_LIBS as override for LIBS
+
+* Scan configure.in using traces as autoheader does.
+  This will be much more reliable.
+
 * Test subdir-objects option with yacc, lex, ansi2knr
   Our locking scheme won't prevent a parallel make from losing
   if there are two `bar.o' files and the timing is just right
   try to find a losing compiler and see if it really works.
   (actually: hack config.cache and do it)
 
-* We're using `$<' in explicit rules when using per-exe flags
-  per-exe flags don't work for CPPFLAGS/YFLAGS/LFLAGS.  Fix.
-  LIBOBJS shouldn't be used when there are per-exe flags (?)
-
-* test `make clean' with subdir-objects
+* per-exe flags
+** We're using `$<' in explicit rules when using per-exe flags
+** per-exe flags don't work for CPPFLAGS/YFLAGS/LFLAGS.  Fix.
+** LIBOBJS shouldn't be used when there are per-exe flags (?)
 
 * Test nodist_SOURCES with lex, yacc, etc.
 
 * Support subdir-objects with fortran
 
 * Allow creation of Java .zip/.jar files in natural way
+  If you are building a compiled Java library, then the .zip/.jar
+  ought to be made automatically.
 
 * Run automake before libtool.  It will report an error but
   still won't put the file into the disty.  This is wrong.
 * CFLAGS only defined if C source seen
   but really it should be a configure variable, shouldn't it?
   There are other examples of this
+  [ moving to autoconf --trace ought to fix this ]
 
 * in gnu/gnits mode, give error if Makefile.am overrides a user
   variable like CFLAGS.
+  [ this is low priority because the package author can always
+    circumvent our check by redefining in configure.in
+    plus it is probably better to encourage good behavior than to
+    punish bad ]
 
 * If we see `foo.o' in LIBOBJS, and we've seen AC_OBJEXT, then complain.
-
-* using "include" inside a conditional doesn't currently
-  work properly.
+  [ how will we know that?  it is better to handle this automatically
+    via an autoconf hook ]
 
 * examine possibility of using any character in a macro name
   and rewriting names automatically.  this means we must rewrite
   all references as well.
+  [ this is a 2.0-style feature ]
 
 * AM_CONFIG_HEADER might generate the wrong stamp file names
   when given multiple headers.  Write a test.
 
 * Currently don't correctly handle multiple inputs to a config header.
+  [ this should no matter in the future as acconfig.h and so on are
+    obsoleted by the AH series of macros.]
 
 * header stamp files still in wrong dirs.
   stamp-h.in must be in dir with h.in file
   stamp-h must be in dir with output file
 
+* conditionals and macros
+  Our current scheme cause combinatoric explosion.
+
+  In fact, to be honest, I no longer understand very well why we perform
+  such a closure.  I mean, as is, Automake transforms (this is
+  cond3.test)
+
+    | bin_PROGRAMS = targ
+    |
+    | if ONE
+    | SONE = one.c
+    | else
+    | SONE =
+    | endif
+    |
+    | if TWO
+    | STWO = two.c
+    | else
+    | STWO =
+    | endif
+    |
+    | if THREE
+    | STHREE = three.c
+    | else
+    | STHREE =
+    | endif
+    |
+    | targ_SOURCES = $(SONE) $(STWO) $(STHREE)
+
+  into
+
+    | @ONE_FALSE@@THREE_FALSE@@TWO_TRUE@am_targ_OBJECTS = two.$(OBJEXT)
+    | @ONE_FALSE@@THREE_FALSE@@TWO_FALSE@am_targ_OBJECTS =
+    | @ONE_FALSE@@THREE_TRUE@@TWO_TRUE@am_targ_OBJECTS = two.$(OBJEXT) \
+    | @ONE_FALSE@@THREE_TRUE@@TWO_TRUE@ three.$(OBJEXT)
+    | @ONE_FALSE@@THREE_TRUE@@TWO_FALSE@am_targ_OBJECTS = three.$(OBJEXT)
+    | @ONE_TRUE@@THREE_FALSE@@TWO_TRUE@am_targ_OBJECTS = one.$(OBJEXT) \
+    | @ONE_TRUE@@THREE_FALSE@@TWO_TRUE@ two.$(OBJEXT)
+    | @ONE_TRUE@@THREE_FALSE@@TWO_FALSE@am_targ_OBJECTS = one.$(OBJEXT)
+    | @ONE_TRUE@@THREE_TRUE@@TWO_TRUE@am_targ_OBJECTS = one.$(OBJEXT) \
+    | @ONE_TRUE@@THREE_TRUE@@TWO_TRUE@ two.$(OBJEXT) three.$(OBJEXT)
+    | @ONE_TRUE@@THREE_TRUE@@TWO_FALSE@am_targ_OBJECTS = one.$(OBJEXT) \
+    | @ONE_TRUE@@THREE_TRUE@@TWO_FALSE@ three.$(OBJEXT)
+
+  why don't we just output
+
+    | @ONE_TRUE@am_SONE_OBJECTS = one.$(OBJEXT)
+    | @ONE_FALSE@am_SONE_OBJECTS =
+    |
+    | @TWO_TRUE@am_STWO_OBJECTS = two.$(OBJEXT)
+    | @TWO_FALSE@am_STWO_OBJECTS =
+    |
+    | @THREE_TRUE@am_STHREE_OBJECTS = three.$(OBJEXT)
+    | @THREE_FALSE@am_STHREE_OBJECTS =
+    |
+    | am_targ_OBJECTS = $(am_SONE_OBJECTS) $(am_STWO_OBJECTS) $(am_STHREE_OBJECTS)
+
+  which means also, why do we look for the closure of PROGRAMS, instead
+  of just adding $(EXEEXT) to all its components and sub components
+  (i.e., inside sub vars such as $(SONE) above being a sub var of
+  targ_SOURCES)?
+
+
+  Aaaaaaaaaaah!  I think I know... Must be because of `+='.
+
+  Hm... No.  Indeed we transform
+
+    | FOO = foo
+    | if BAR
+    | FOO += BAR
+    | endif
+
+  into
+
+    | @BAR_TRUE@FOO = foo bar
+    | @BAR_FALSE@FOO = foo
+
+  but this seems good to me too?
+
+    | FOO = foo $(BAR_FOO)
+    | @BAR_TRUE@BAR_FOO = bar
+    | @BAR_FALSE@BAR_FOO =
+
+
 * foo=bar
   if cond
   foo += joe
   endif
-  ... this ought to work.  The fix is probably complicated
+  ... this ought to work.  The fix is probably complicated, but might
+  come for free when we rewrite the handling of conditionals.
 
 * `distcheck' and `dist' should depend on `all'
 
-* Document why putting @FOO@ in _SOURCES doesn't work.
-  Make it an error when the user tries to do this
-
 * Add code to generate foo-config script like gnome, gtk
 
 * `DEFS += foo' won't work.
   This will be a problem for any macro defined internally
     [ fixing this will probably fix the nasty `exeext redefines
       foo_PROGRAMS' hack that is in there right now ]
-  In some cases this is unfixable.  In these cases we should give
-  an error.  This can be done by keeping track of whether a macro
-  was assigned with `=' or `+=', and having define_variable give
-  an error if the variable exists and was defined with +=.
+    [ we currently give an error when this occurs, so this is very low
+      priority ]
 
 * document user namespace for macro/target names
   adopt some conventions and use uniformly
   (maybe doesn't matter since people who even know about
   maintainer-clean already have a clue)
 
-* There are probably more bugs in variable_conditions_sub along
-  the lines of the one that caused cond4.test to fail.
-
-* give user more control over -I flags
-  in particular document a way to override the defaults
-
 * reintroduce AM_FUNC_FNMATCH which sets LIBOBJS
   Then have automake know about fnmatch.h.
     [ probably should wait for autoconf to get right functionality ]
 
-* Add a conditional for dependency tracking
-  (what to name it is the biggest problem here)
-  (because we want it to flag dist/no-dist -- not just deps)
-    [ this might not really be correctly doable.
-      instead we need a compile-time conditional for this
-      yuck ]
-
-* Allow per-object cflags:
-       bin_PROGRAMS = foo
-       foo_CFLAGS = -DFOO
-* per-object compiler flags do not apply to libobjs
-  -> give error in this case
-* At the same time, allow sources in subdirs:
-       foo_SOURCES = x/y.c
-  This requires `mkdir x' at build time
- [ both of these require per-file rules, and not pattern rules ]
- [ use user-written suffix rules to generate the per-file rules in
-   an automatic way -- this would be mucho cool ]
-
-* Allow for multiple translations of a texinfo file:
-       LL_info_TEXINFOS = ...
-  will put info files for language LL into $(infodir)/LL.
-
-* If you suppress an internal variable by specifying a variable
-  in a Makefile.am, but the variable is conditional, then automake
-  should generate the internal variable conditionally.
-  You have to scan the map of all conditions and fill in the holes here
-
-* Every program foo has FOOFLAGS right now.
-  It should also have AM_FOOFLAGS, which can be set in Makefile.am.
-DONE: but needs to be documented
-
-* Should be able to update files that would be installed with -a
-  (--force?)
-
 * "make diff" capability
   look at gcc's Makefile.in to see what to do
   or look at maint program
 
-* Karl wants to be able to set LIBS and LDFLAGS at build time, like CFLAGS
-  maybe we need something more general?
-
-* add $(srcdir)/ before some dependencies?
-
-* define LINK if a program is mentioned, even if no C sources appear
-
-* BUILT_SOURCES should not be distributed, even when they appear in
-  another _SOURCES line. [? or maybe just leave this up to the
-  to-be-defined generic distribution method ]
-  must completely revisit the entire BUILT_SOURCES idea
-
 * in --cygnus, clean-info not generated at top level
 
 * what if an element of a scanned variable looks like
        $(FOO).$(BAR)  ?
   or some other arbitrary thing?
   right now we try to cope, but not very well
+    [ this is only of theoretical interest for now ]
 
-* if `interlock' exists, that should be an error (?)
-  should also warn about using new ylwrap and not old one
-  only do this when looking for ylwrap
-
-** make sure every variable that is used is also defined
+* make sure every variable that is used is also defined
+    [ we don't really look at variable uses in detail.
+      2.0 thing ]
 
 * make sure `missing' defines are generated
-* if no AM_INIT_AUTOMAKE, then don't handle `missing' stuff.
-  Yuck!
+
 * missing should handle install -d and rmdir -p (for uninstall)
 
-* a couple ways to be smarter:
-  - notice when a .c file is a target somewhere, and auto-add it to
+* notice when a .c file is a target somewhere, and auto-add it to
     BUILT_SOURCES
-  - notice a target of the form `.x.y:' and assume it is a suffix rule
-
 
 * NORMAL_INSTALL / NORMAL_UNINSTALL -vs- recursive rules
   [ requires changes to the standard ]
 
-* cross-compilation support:
-  programs built and used by the build process need to be
-  built for CC_FOR_BUILD
-  introduce a new variable for this
-
-* if foo.y is a source, foo.h isn't auto-distributed?
-
 * copyrights on m4 files, aclocal output
 
-* is there a way to add a directory and then have "make" do all the
-  updating?  think.
-
-* put standards.texi into distribution
-
-
 * should not put texiname_TEXINFOS into distribution
   should rename this macro anyway, to foo_texi_DEPENDENCIES
 
 * *all* installed scripts should support --version, --help
 
-For now I guess I'll just have automake give an error if it encounters
+For now I guess I'll just have automake give an error if it encounters
 non-C source in a libtool library specification.
 
 * must split $obj into two parts: one for libtool and one for
@@ -213,12 +349,7 @@ non-C source in a libtool library specification.
   strictness should only cover requirements
   You should be able to pick and choose options
 
-should clean up texinfos.am; one rule is repeated 3 times, but
-shouldn't be
-
-should always use perl -w
-
-rewrite in guile (RMS request)
+* rewrite in guile (RMS request)
 at the same time, consider adding a GUI
 could use the same parsing code for the GUI and the standalone version
 that means figuring out a better representation of internal state
@@ -230,8 +361,6 @@ still be able to have a Makefile.am in each directory somehow; this
 might make editing conceptually easier.
 
 * finish up TAGS work
-* `acinstall'
-* put parser.h into distribution if "yacc -d" is used
 
 * only remove libtool at top level?
 
@@ -286,22 +415,11 @@ Per> .class files from a list of .java source files.
 !! Must fix require_file stuff.  It is really gross, and I don't
    understand it any more.
 
-* error messages should print ``[info blah blah]'' command when a
-  certain part of the standards apply.  saw idea in message from
-  Craig Burley.  wouldn't it be really cool if compile-mode in Emacs
-  understood this convention, and you could click on such text to
-  go to the appropriate info page?  [ I think you can ]
-
 Jim's idea: should look for @setfilename and warn if filenames too long
 * guess split size
 
-** many requests for a way to omit a file from the distribution.
-   Should be done like `!foo' or `~foo' in _SOURCES, etc.
-   Such files should be removed explicitly after the copy step!
-   Doing this requires rewriting macros before generating Makefile.in.
-
 from joerg-martin schwarz:
- -- If Makefile.am contains $(CC), $(COMPILE), $(YLWRAP), .... 
+ -- If Makefile.am contains $(CC), $(COMPILE), $(YLWRAP), ....
     in an explicitly written rule,  you should emit the corresponding
     Makefile variables automatically.
 
@@ -330,19 +448,6 @@ should be able to determine what is built by looking at rules (and
 configure.in).  Then built man pages (eg) could automatically be
 omitted from the distribution.
 
-Idea from Joerg-Martin Schwarz: allow passing different -D flags to
-different compiles.  This can be done, but with the restriction that a
-.c cannot appear in 2 different "objects" (programs/libraries)
-compiled with different -D options (because -c and -o do not always
-work together and parallel makes must work).  This could be
-implemented by noticing whenever a ".o" target with no rules is being
-emitted, and adding the appropriate compilation rule as appropriate.
-This should work with targets from Makefile.am as well as from .P
-files, which means rewriting so that the Makefile.am contents aren't
-copied into the output immediately.
- [ this could be probably done more directly by examining the sources
-   as we scan Makefile.am ]
-
 Henrik Frystyk Nielsen says:
 Henrik> 4) Flags like --include-deps are lost when you make changes to
 Henrik> Makefile.am files and automake is run automatically. It would
@@ -383,18 +488,6 @@ Need way to say there are no suffixes in a Makefile (Franc,ois'
 Check to make sure various scripts are executable (IE when looking for
 them in a directory)
 
-Use recode in dist target when MAINT_CHARSET specified.  Read caveats
-in automake.in before doing this.  Note the same problem used to apply
-to the no-dependencies option; maybe it still should?  Note also that
-each Makefile.am must be rewritten at "make dist" time if
-MAINT_CHARSET and DIST_CHARSET are not identical.  NOTE: gettext must
-arrange for all .po files not to be recoded.  In the long term this
-might be a problem (consider when some systems use Unicode but the
-rest do not)
-  MAINT_CHARSET *must* be local to each Makefile.am, to enable
-       merged distributions.
-  DIST_CHARSET must be passed down to subdir makes during a "make dist"
-
 Handle dist-zoo.  Generally add more DOS support.  Maybe run "doschk"
 (why isn't this merged with "pathchk"?) when doing a dist.  Do
 whatever else François says here...
@@ -416,28 +509,28 @@ things to be removed.  This would be a lot nicer looking.  Note that
 the install targets probably should not be merged; it is sometimes
 useful to only install a small part.
 
-Clean up the output:
-* Order rules sensibly
-* Ensure every line has a purpose.  Omit unused stuff
-* Eliminate extraneous rules when possible (eg 'install-am' stuff)
-* Make sure vertical spacing is correct
+Clean up the output:
+** Order rules sensibly
+** Ensure every line has a purpose.  Omit unused stuff
+** Eliminate extraneous rules when possible (eg 'install-am' stuff)
+** Make sure vertical spacing is correct
 Omit program transform vars from header if no program installed.  This
 is currently pretty hard to do.  (But with beautification code it
 would probably be easy)
 
-Lex, yacc support:
-* It would be nice to automatically support using bison's better features
+Lex, yacc support:
+** It would be nice to automatically support using bison's better features
   to rename the output files.  This requires autoconf support
-* Consider supporting syntax from autoconf "derived:source", eg:
+** Consider supporting syntax from autoconf "derived:source", eg:
        y.tab.c:perly.y
   for yacc and lex source
-* what if you use flex and the option to avoid -lfl?
+** what if you use flex and the option to avoid -lfl?
   should support this?
 
-Multi-language support:
-* should have mapping of file extensions to languages
-* should automatically handle the linking issue (special-case C++)
-* must get compile rules for various languages; FORTRAN probably
+Multi-language support:
+** should have mapping of file extensions to languages
+** should automatically handle the linking issue (special-case C++)
+** must get compile rules for various languages; FORTRAN probably
   most important unimplemented language
 This should be integrated in some way with Per's idea.
 Eg .f.o rules should be recognized & auto-handled in _SOURCES
@@ -574,14 +667,6 @@ Then automake can use -MD -MH -MT 'foo.o foo.lo' -MF .deps/...
 
 ================================================================
 
-Things to do for autoconf:
-
-* patch autoreconf to run automake and aclocal.  I've done this but it is
-  not really available.  It can't be made available until automake
-  is officially released
-
-================================================================
-
 Libraries:
 
 * Should support standalone library along with subdir library in same
@@ -652,19 +737,6 @@ could eliminate a common source of problems.
   [ the consensus on Gnits is that this isn't required.
     doubters can work around it anyway ]
 
-* make the auto-dep code crash if GNU make not in use?
-  (doesn't it already?)
-
-Looked at a program called 'ezmake', which seems to do something
-similar.  The only idea there that is possibly worth stealing is using
-globs in definitions.  Also has negations.  Eg in a directory with
-files a.c, b.c and c.c, the line:
-       foo_SOURCES = *.c ~c.c
-would be equivalent to:
-       foo_SOURCES = a.c b.c
-Is this worth implementing?
-  [ No... it is more reliable to spell everything out. ]
-
 Scan source directories and warn about missing files, eg .c/.h files
 that aren't mentioned?
   [ distcheck makes this less useful ]
@@ -672,3 +744,30 @@ that aren't mentioned?
 * quoting bugs
   - how to install file with a space in its name?
   [ don't bother with this -- make is just too losing ]
+
+* copyright notice
+
+Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001 Free Software
+Foundation, Inc.
+
+This file is part of GNU Automake.
+
+GNU Automake is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU Automake is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with autoconf; see the file COPYING.  If not, write to
+the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.
+
+
+Local Variables:
+mode: outline
+End: