diff options
Diffstat (limited to 'old/TODO')
| -rw-r--r-- | old/TODO | 504 |
1 files changed, 504 insertions, 0 deletions
diff --git a/old/TODO b/old/TODO new file mode 100644 index 000000000..f8e4754df --- /dev/null +++ b/old/TODO @@ -0,0 +1,504 @@ +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 + +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 ] + +* 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 +** LIBOBJS shouldn't be used when there are per-exe flags (?) + +* 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. + +* 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 ] + +* `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 ] + +* 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 ] + [ We now have an 'inner_expand' option to traverse_recursively, + but it is not yet used. ] + +* 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 + +* missing should handle install -d and rmdir -p (for uninstall) + +* NORMAL_INSTALL / NORMAL_UNINSTALL -vs- recursive rules + [ requires changes to the standard ] + +* should not put texiname_TEXINFOS into distribution + should rename this macro anyway, to foo_texi_DEPENDENCIES + +* For now I guess I'll just have automake give an error if it encounters +non-C source in a libtool library specification. + +* 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 + consider auto-modifying the program name to work around this + +* should separate actual options from strictness levels + strictness should only cover requirements + You should be able to pick and choose options + +having just one Makefile for a project would give a big speed increase +for a project with many directories, eg glibc. ideally (?) you'd +still be able to have a Makefile.am in each directory somehow; this +might make editing conceptually easier. + +* finish up TAGS work + +* only remove libtool at top level? + +* clean up source directory by moving stuff into subdirs + +* consider adding other variables similar to pkglibexecdir? + requests for pkg-dirs with version included + +Avoid loops when installing; instead unroll them in automake +[ Impossible when @AC_SUBST@ values are used. ] + +Some long-term projects: +* if $(FOO) is used somewhere, ensure FOO is defined, either by + user or by automake if possible + +[ 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? + +take diff-n-query code from libit + +Per Bothner says: +Per> 1) Being able to build a set of non-source programs +Per> from source programs, without necessarily linking them together. +Per> I.e. one should be able to say something like: +Per> dummy_SOURCES=foo.c bar.c +Per> and automake should realize that it needs to build foo.o and bar.o. +Per> 2) Being intelligent about new kinds of suffixes. +Per> If it sees: +Per> SUFFIXES = .class .java +Per> and a suffix rule of the form: +Per> .java.class: +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.] + +Jim's idea: should look for @setfilename and warn if filenames too long +* guess split size + +from joerg-martin schwarz: + -- If Makefile.am contains $(CC), $(COMPILE), $(YLWRAP), .... + in an explicitly written rule, you should emit the corresponding + Makefile variables automatically. + +From the GNU Standards. These things could be checked, and probably +should be if --gnu. +* Make sure that the directory into which the distribution unpacks (as +well as any subdirectories) are all world-writable (octal mode 777). +* Make sure that no file name in the distribution is more than 14 +characters long. +* 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. + +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. + +Right now, targets generated internally (eg "install") are not +overridable by user code. This should probably be possible, even +though it isn't very important. This could be done by generating all +internal rules via a function call instead of just appending to +$output_rules. + [ this will be harder to implement when scanning a rule like all-recursive + from subdirs.am ] + +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. +* Fix up require_file junk. + +djm wants ``LINKS'' variable; list of things to link together after +install. In BSD environment, use: + LINKS = from1 to1 from2 to2 ... + +Need way to say there are no suffixes in a Makefile (Franc,ois' +"override" idea suffices here) + +Check to make sure various scripts are executable (IE when looking for +them in a directory) + +Add support for html via an option. Use texi2html. Use +"html_TEXINFOS", and htmldir = .../html. Include html files in +distribution. Also allow "html_DATA", for raw .html files. + [ when will texinfo directly support html? ] +See also Karl Berry's message on a roadmap for a "info -> html" +transition: +<http://lists.gnu.org/archive/html/texinfo-devel/2012-03/msg00018.html> + +uninstall and pkg-dirs should rm -rf the dir. + +In general most .am files should be merged into automake. For +instance all the "clean" targets could be merged by keeping lists of +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. + +* 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: + y.tab.c:perly.y + for yacc and lex source +** 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 + 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 +That way any random language can be treated with C/C++ on a first-class +basis (maybe) + +It might be cool to generate .texi dependencies by grepping for +@include. (If done, it should be done the same way C dependencies are +done) +[ Ask Karl Berry for a -M option to makeinfo and texi2dvi? ] + +It would be good to check some parts of GNU standards. Already check +for install-sh and mkinstalldirs. What else is required to be in +package by GNU standards or by automake? +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_S) and AC_PROG_LN_S +* Look for $(LN_S) and require AC_PROG_LN_S + +Auto-distribute "ChangeLog.[0-9]+"? "ChangeLog.[a-z]+"? + +Check all source files to make sure that FSF address is up-to-date. +--gnits or --gnu only. + +Merge each -vars.am file with corresponding ".am" file. Can do this +because of changes to &file_contents. + +Should libexec programs have the name transform done on them? + +Order the output rules sensibly, so FOO_SOURCES and FOO_OBJECTS are +together and rules are in the usual order. + +djm says: +David> To avoid comments like the one about subdirs getting buried in +David> the middle of a Makefile.in, how about pushing comments that +David> start with ### to the top of the Makefile.in (in order)? Sort +David> of like how Autoconf uses diversions to force initialization +David> code to the top of configure. + +================================================================ + +Stuff for aclocal: + +probably should put each group of m4 files into a subdir owned by the +containing application. + +================================================================ + +Document: + +AM_MISSING_PROG + +how to use the generated makefiles + - standard targets + - required targets + - NORMAL_INSTALL junk + +rationale for avoiding + make CFLAGS="$CFLAGS" ... +in subdirs make rule + +write example of using automake with dejagnu +follow calc example in dejagnu docs + +document which variables are actually scanned and which are not. + +Document customary ordering of Makefile.am. From François. + +Should include extended version of diagram from Autoconf (suggested by +Greg Woods) + +Make a definition of the term "source" + +document how to use Automake with CVS. Idea from Mark Galassi. Also +include Greg Woods' more sophisticated "cvs-dist" target. + +-- must document all variables that are supposed + to be public knowledge + +must document the targets required for integration with +non-automake-using subdirs + +document the "make SHELL='/bin/sh -x'" trick for debugging + +section on relationship to GNU make. include notes on parallel makes + +add a concept index + +move discussion of cygwin32, etags, mkid under other gnu tools + +CCLD, CXXLD, FLD + +================================================================ + +Libraries: + +* Should support standalone library along with subdir library in same + Makefile.am. Maybe: turn off "standalone" mode if library's Makefile.am + is not only one specd? [ add an option for this ] + +================================================================ + +Longer term: + +Would it be useful to integrate in some way with the Debian package +building utility? Must check. maybe it would be possible to deal +with all the different package utilities somehow. Lately I've been +hearing good things about the RedHat packaging utilities. Why are +there so many of these? Are they fun to write or something? +The RedHat package utility is called RPM; see + ftp://ftp.redhat.com/pub/code/rpm +It actually has problems, like no configure script and no documentation. + +For Cygnus it would probably be good to be able to handle the native +package utility on each platform. There are probably 3 or 4 of these +(sysv, solaris?, aix?) + +tcl/unix/Makefile.in has some code to generate a Solaris package. + +Automake probably can't do all of this on its own. A new tool might +be a better idea + +I have some notes from a Debian developer on how the integration +should work + +================================================================ + +A tool to guess what the local Makefile.am should look like: +(see Gord's Maint program!) + +* Probably integrate with autoscan +* Use various simple rules to determine what to do: + * get name of top directory, sans version info + * search for .c files with 'main' in them + * if in main.c, use directory name for program + * if in more than one, generate multiple programs + * if not found, generate a library named after directory + * order subdir searches correctly: lib first, src last + * assume 'testsuite' dir means we are using dejagnu +* maybe be smart about reading existing Makefile.am, so tool + can be run for incremental changes? You could imagine: + + Makefile.am: + autoproject --incremental + +================================================================ + +Stuff NOT to do, and why: + +consider auto-including any file that matches "*.in". + [ no: po/Makefile.in shouldn't be included ] + +must look at mkid to see how it works (for subdir usage) + [ right now, it doesn't. i don't see a simple fix right now ] + +if configure.in not found, move up a directory and try again? This +could eliminate a common source of problems. + [ this is just a bad idea ] + +* scripts are installed in $exec_prefix/bin, not $prefix/bin + Bug or feature? + [ the consensus on Gnits is that this isn't required. + doubters can work around it anyway ] + +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) ] + +* Scan multiple input files when Makefile is generated? + This would provide flexibility for large projects; subsumes + the "Makefile.tmpl" idea + [ can't do this. must explain why in manual. + basically, solving all the problems is too hard + like: how to remove redundancies between generated .in files + instead should implement `include' directive for Makefile.am ] + +* Should be a way to have "nobuild_PROGRAMS" which aren't even built, + but which could be by running the magic make command. + [ We already have EXTRA_PROGRAMS for this. ] + + +* copyright notice + +Copyright 1994-2012 Free Software Foundation, Inc. + +This program 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. + +This program 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 this program. If not, see <http://www.gnu.org/licenses/>. + + +Local Variables: +mode: outline +End: |