diff options
Diffstat (limited to 'old/TODO')
| -rw-r--r-- | old/TODO | 504 |
1 files changed, 0 insertions, 504 deletions
diff --git a/old/TODO b/old/TODO deleted file mode 100644 index 59335d8bb..000000000 --- a/old/TODO +++ /dev/null @@ -1,504 +0,0 @@ -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.ac). 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.ac 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-2014 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: |