-* update text in missing
- avoid passive voice
-
-* 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
+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
+
+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
+
+for 1.5
+investigate problems with conditionally defined libraries
+
+add an error if the user makefile.am violates our
+ namespace rules
+
+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
+
+* 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
+ This only happens with parallel make and no-`-c -o' compiler,
+ so it probably isn't very important
+ `-c -o' when doing libtool
+ try to find a losing compiler and see if it really works.
+ (actually: hack config.cache and do it)
+
+* 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.
+ From Mark H Wilkinson <mhw@kremvax.demon.co.uk>
+
+* 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 ]
+
+* 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.]
+
+* `distcheck' and `dist' should depend on `all'
+
+* Add code to generate foo-config script like gnome, gtk
+
+* document user namespace for macro/target names
+ adopt some conventions and use uniformly
+ [ this is a good thing for the rewrite ]
+
+* make distcheck uses directories like `=build'.
+ Some (very rare) POSIX systems don't support `=' in filenames.
+ If this ever becomes a problem, fix it
+
+* distclean must remove config.status
+ can't this cause problems for maintainer-clean?
+ shouldn't maintainer-clean print the message before running
+ any part of the make? (just to slow things down long enough
+ for the user to stop it)
+ (maybe doesn't matter since people who even know about
+ maintainer-clean already have a clue)
+
+* reintroduce AM_FUNC_FNMATCH which sets LIBOBJS
+ Then have automake know about fnmatch.h.
+ [ probably should wait for autoconf to get right functionality ]
+
+* "make diff" capability
+ look at gcc's Makefile.in to see what to do
+ or look at maint program
+
+* 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 ]
+
+* 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)
-
-* allow 'cygnus' in AUTOMAKE_OPTIONS
-
-* a couple ways to be smarter:
- - 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
+* missing should handle install -d and rmdir -p (for uninstall)
* NORMAL_INSTALL / NORMAL_UNINSTALL -vs- recursive rules
[ requires changes to the standard ]
-* if foo.y is a source, foo.h isn't auto-distributed?
-
-* dependency tracking doesn't work well when a file is removed
- the new code to track header dependencies exacerbates this
- what is the fix?
- it would probably be better to use "gcc -MD" and move the .d
- file into the .deps directory. That is, create the dependencies
- as a side effect of compilation
- This still won't solve the file-deletion problem
- [ also: jim makes distributions by checking out, configuring,
- and running "make dist". This scheme would cause that to fail ]
-
* 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
-
-* have aclocal diagnose unrecognized AM_ macros
-
-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
deansification. Otherwise .S files will be deansified!
+* ansi2knr must currently appear in a directory that has some source
+
* if program has the same name as a target, do something sensible:
- if the target is internal, rename it
- if the target is mandated (eg, "info"), tell the user
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
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?
* consider adding pkglibexecdir, maybe others?
requests for pkg-dirs with version included
-Further:
-- man page fixes
-
Avoid loops when installing; instead unroll them in automake
+[ Impossible when @AC_SUBST@ values are used. ]
* for new autoconf:
* completely handle multi-":" mode for AC_CONFIG_HEADER
Some long-term projects:
* if $(FOO) is used somewhere, ensure FOO is defined, either by
user or by automake if possible
-* Don't rearrange order of `include' lines relative to += assignments.
-* Handle += assignments at all.
-* Handle `include' lines by scanning other files, and adding
- to Makefile.in dependency
+
+[ include, += support ]
+* even better would be allowing targets in different included
+ fragments to be merged. e.g., `install-local'.
consider putting all check-* targets onto @check?
-To support --help/--version checking?
take diff-n-query code from libit
Per> then it should be able to realize it can build .class files from
Per> .java files, and thus be able to generate a list of
Per> .class files from a list of .java source files.
+[What Per wanted here was a way to have automate automatically follow
+suffix rules. So for instance if you had a `.x.y:' rule, and automake
+saw a `.x' file, it would automatically build and install the
+corresponding `.y' file.]
!! 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?
-
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.
* Don't include any symbolic links in the distribution itself.
(ditto hard links)
* Make sure that all the files in the distribution are world-readable.
-** also, check --help output and --version output. Idea from François
* standards no longer prohibit ANSI C. What does this imply
- for the de-ansi-fication feature?
-
-consider supporting "var+= stuff" syntax. rewrite to just var=... on
-output. This is sometimes convenient when you want to write a
-Makefile.am in more-or-less modular parts
+ for the de-ansi-fication feature? [ must keep it -- some users rely on it ]
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
-Henrik> be nice to keep these flags as I now have to redo everything
-Henrik> manually.
-... what about other options here too?
-
-Think about: maybe "make check" should just bomb if error occurs?
-Then user must use "make -k check". This is probably more natural.
-
Consider: "cvs" option adds some cvs-specific rules?
Right now, targets generated internally (eg "install") are not
* Should be a way to have "nobuild_PROGRAMS" which aren't even built,
but which could be by running the magic make command.
+ [ How does it differ from EXTRA_PROGRAMS? ]
Other priorities:
* Must rewrite am_install_var. Should break into multiple functions.
This will allow the callers to be a little smarter.
* Rewrite clean targets.
-* Must rewrite error handling code. Right now it is a real mess
- Should fix up require_file junk at the same time
+* Fix up require_file junk.
djm wants ``LINKS'' variable; list of things to link together after
install. In BSD environment, use:
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...
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
Some things for --strictness=gnits:
* "cd $(foo); something" is an error in a rule. Should be:
"cd $(foo) && something"
-* Look for 'ln -s' and warn about using $(LN) and AC_PROG_LN_S
-* Look for $(LN) and require AC_PROG_LN_S
+* Look for 'ln -s' and warn about using $(LN_S) and AC_PROG_LN_S
+* Look for $(LN_S) and require AC_PROG_LN_S
Auto-distribute "ChangeLog.[0-9]+"? "ChangeLog.[a-z]+"?
include Greg Woods' more sophisticated "cvs-dist" target.
document rebuilding configure. CONFIGURE_DEPENDENCIES
+CONFIG_STATUS_DEPENDENCIES
-- must document all variables that are supposed
to be public knowledge
move discussion of cygwin32, etags, mkid under other gnu tools
-================================================================
-
-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
+CCLD, CXXLD, FLD
================================================================
[ 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 ]
+
+* quoting bugs
+ - how to install file with a space in its name?
+ [ don't bother with this -- make is just too losing ]
+
+* notice when a .c file is a target somewhere, and auto-add it to
+ BUILT_SOURCES
+ [ BUILT_SOURCES are for files that need to be built before anything
+ else because of hidden dependencies (something .c files are
+ unlikely to be) ]
+
+
+* copyright notice
+
+Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002 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:
projects / platform / upstream / automake.git / blobdiff