1 * There are probably more bugs in variable_conditions_sub along
2 the lines of the one that caused cond4.test to fail.
4 * give user more control over -I flags
5 in particular document a way to override the defaults
7 * reintroduce AM_FUNC_FNMATCH which sets LIBOBJS
8 Then have automake know about fnmatch.h.
10 * Reimplement maintainer mode to use conditionals
11 Also add a conditional for dependency tracking
13 * Allow per-object cflags:
17 * Allow for multiple translations of a texinfo file:
18 LL_info_TEXINFOS = ...
19 will put info files for language LL into $(infodir)/LL.
21 * dependency tracking doesn't work well when a file is removed
22 the new code to track header dependencies exacerbates this
24 ANSWER: for each dependency foo.h, make a dummy target `foo.h:'
25 in the .P file. Then the right thing ought to happen
27 * If you suppress an internal variable by specifying a variable
28 in a Makefile.am, but the variable is conditional, then automake
29 should generate the internal variable conditionally.
30 You have to scan the map of all conditions and fill in the holes here
32 * Every program foo has FOOFLAGS right now.
33 It should also have AM_FOOFLAGS, which can be set in Makefile.am.
34 DONE: but needs to be documented
36 * Should have a --copy like libtoolize
37 Should be able to update files that would be installed with -a
39 * when cleaning, should recurse depth first
42 - how to install file with a space in its name?
44 * "make diff" capability
45 look at gcc's Makefile.in to see what to do
46 or look at maint program
48 * Karl wants to be able to set LIBS and LDFLAGS at build time, like CFLAGS
49 maybe we need something more general?
51 * add $(srcdir)/ before some dependencies?
53 * mention PACKAGE/VERSION -vs- autoheader in manual
55 * define LINK if a program is mentioned, even if no C sources appear
57 * BUILT_SOURCES should not be distributed, even when they appear in
58 another _SOURCES line. [? or maybe just leave this up to the
59 to-be-defined generic distribution method ]
60 must completely revisit the entire BUILT_SOURCES idea
62 * in --cygnus, clean-info not generated at top level
64 * what if an element of a scanned variable looks like
66 or some other arbitrary thing?
67 right now we try to cope, but not very well
69 * if `interlock' exists, that should be an error (?)
70 should also warn about using new ylwrap and not old one
71 only do this when looking for ylwrap
73 ** make sure every variable that is used is also defined
75 * make sure `missing' defines are generated
76 * if no AM_INIT_AUTOMAKE, then don't handle `missing' stuff.
78 * missing should handle install -d and rmdir -p (for uninstall)
80 * allow 'cygnus' in AUTOMAKE_OPTIONS
82 * a couple ways to be smarter:
83 - notice when a .c file is a target somewhere, and auto-add it to
85 - notice a target of the form `.x.y:' and assume it is a suffix rule
88 * NORMAL_INSTALL / NORMAL_UNINSTALL -vs- recursive rules
89 [ requires changes to the standard ]
91 * cross-compilation support:
92 programs built and used by the build process need to be
93 built for CC_FOR_BUILD
94 introduce a new variable for this
96 * if foo.y is a source, foo.h isn't auto-distributed?
98 * copyrights on m4 files, aclocal output
100 * is there a way to add a directory and then have "make" do all the
103 * put standards.texi into distribution
106 * should not put texiname_TEXINFOS into distribution
107 should rename this macro anyway, to foo_texi_DEPENDENCIES
109 * *all* installed scripts should support --version, --help
111 For now I guess I'll just have automake give an error if it encounters
112 non-C source in a libtool library specification.
114 * must split $obj into two parts: one for libtool and one for
115 deansification. Otherwise .S files will be deansified!
117 * ansi2knr must currently appear in a directory that has some source
119 * if program has the same name as a target, do something sensible:
120 - if the target is internal, rename it
121 - if the target is mandated (eg, "info"), tell the user
122 consider auto-modifying the program name to work around this
124 * should separate actual options from strictness levels
125 strictness should only cover requirements
126 You should be able to pick and choose options
128 should clean up texinfos.am; one rule is repeated 3 times, but
131 should always use perl -w
133 rewrite in guile (RMS request)
134 at the same time, consider adding a GUI
135 could use the same parsing code for the GUI and the standalone version
136 that means figuring out a better representation of internal state
137 [ that's easy -- anything is better than what we have now ]
139 having just one Makefile for a project would give a big speed increase
140 for a project with many directories, eg glibc. ideally (?) you'd
141 still be able to have a Makefile.am in each directory somehow; this
142 might make editing conceptually easier.
144 * finish up TAGS work
146 * put parser.h into distribution if "yacc -d" is used
148 * only remove libtool at top level?
150 * clean up source directory by moving stuff into subdirs
152 * consider adding pkglibexecdir, maybe others?
153 requests for pkg-dirs with version included
158 Avoid loops when installing; instead unroll them in automake
161 * completely handle multi-":" mode for AC_CONFIG_HEADER
162 * Scan multiple input files when Makefile is generated?
163 This would provide flexibility for large projects; subsumes
164 the "Makefile.tmpl" idea
166 [ can't do this. must explain why in manual.
167 basically, solving all the problems is too hard
168 like: how to remove redundancies between generated .in files
169 instead should implement `include' directive for Makefile.am ]
170 * for multi-":" mode and AC_OUTPUT, it might be good to pick the
171 first input file that has a corresponding .am file.
173 Some long-term projects:
174 * if $(FOO) is used somewhere, ensure FOO is defined, either by
175 user or by automake if possible
176 * Don't rearrange order of `include' lines relative to += assignments.
177 * Handle += assignments at all.
178 * Handle `include' lines by scanning other files, and adding
179 to Makefile.in dependency
181 consider putting all check-* targets onto @check?
182 To support --help/--version checking?
184 take diff-n-query code from libit
187 Per> 1) Being able to build a set of non-source programs
188 Per> from source programs, without necessarily linking them together.
189 Per> I.e. one should be able to say something like:
190 Per> dummy_SOURCES=foo.c bar.c
191 Per> and automake should realize that it needs to build foo.o and bar.o.
192 Per> 2) Being intelligent about new kinds of suffixes.
194 Per> SUFFIXES = .class .java
195 Per> and a suffix rule of the form:
197 Per> then it should be able to realize it can build .class files from
198 Per> .java files, and thus be able to generate a list of
199 Per> .class files from a list of .java source files.
201 !! Must fix require_file stuff. It is really gross, and I don't
202 understand it any more.
204 * error messages should print ``[info blah blah]'' command when a
205 certain part of the standards apply. saw idea in message from
206 Craig Burley. wouldn't it be really cool if compile-mode in Emacs
207 understood this convention, and you could click on such text to
208 go to the appropriate info page?
210 Jim's idea: should look for @setfilename and warn if filenames too long
213 ** many requests for a way to omit a file from the distribution.
214 Should be done like `!foo' or `~foo' in _SOURCES, etc.
215 Such files should be removed explicitly after the copy step!
216 Doing this requires rewriting macros before generating Makefile.in.
218 from joerg-martin schwarz:
219 -- If Makefile.am contains $(CC), $(COMPILE), $(YLWRAP), ....
220 in an explicitly written rule, you should emit the corresponding
221 Makefile variables automatically.
223 Configuring in the large:
224 * allow hierarchy of dirs to share one aclocal.m4
227 consider printing full file name of Makefile.am or configure.in when
228 giving error. This would help for very large trees with many
231 From the GNU Standards. These things could be checked, and probably
233 * Make sure that the directory into which the distribution unpacks (as
234 well as any subdirectories) are all world-writable (octal mode 777).
235 * Make sure that no file name in the distribution is more than 14
237 * Don't include any symbolic links in the distribution itself.
239 * Make sure that all the files in the distribution are world-readable.
240 ** also, check --help output and --version output. Idea from François
241 * standards no longer prohibit ANSI C. What does this imply
242 for the de-ansi-fication feature?
244 consider supporting "var+= stuff" syntax. rewrite to just var=... on
245 output. This is sometimes convenient when you want to write a
246 Makefile.am in more-or-less modular parts
248 should be able to determine what is built by looking at rules (and
249 configure.in). Then built man pages (eg) could automatically be
250 omitted from the distribution.
252 Idea from Joerg-Martin Schwarz: allow passing different -D flags to
253 different compiles. This can be done, but with the restriction that a
254 .c cannot appear in 2 different "objects" (programs/libraries)
255 compiled with different -D options (because -c and -o do not always
256 work together and parallel makes must work). This could be
257 implemented by noticing whenever a ".o" target with no rules is being
258 emitted, and adding the appropriate compilation rule as appropriate.
259 This should work with targets from Makefile.am as well as from .P
260 files, which means rewriting so that the Makefile.am contents aren't
261 copied into the output immediately.
262 [ this could be probably done more directly by examining the sources
263 as we scan Makefile.am ]
265 Henrik Frystyk Nielsen says:
266 Henrik> 4) Flags like --include-deps are lost when you make changes to
267 Henrik> Makefile.am files and automake is run automatically. It would
268 Henrik> be nice to keep these flags as I now have to redo everything
270 ... what about other options here too?
272 Think about: maybe "make check" should just bomb if error occurs?
273 Then user must use "make -k check". This is probably more natural.
275 Consider: "cvs" option adds some cvs-specific rules?
277 Right now, targets generated internally (eg "install") are not
278 overridable by user code. This should probably be possible, even
279 though it isn't very important. This could be done by generating all
280 internal rules via a function call instead of just appending to
282 [ this will be harder to implement when scanning a rule like all-recursive
285 * Should be a way to have "nobuild_PROGRAMS" which aren't even built,
286 but which could be by running the magic make command.
289 * Must rewrite am_install_var. Should break into multiple functions.
290 This will allow the callers to be a little smarter.
291 * Rewrite clean targets.
292 * Must rewrite error handling code. Right now it is a real mess
293 Should fix up require_file junk at the same time
295 djm wants ``LINKS'' variable; list of things to link together after
296 install. In BSD environment, use:
297 LINKS = from1 to1 from2 to2 ...
299 Need way to say there are no suffixes in a Makefile (Franc,ois'
300 "override" idea suffices here)
302 Check to make sure various scripts are executable (IE when looking for
305 Use recode in dist target when MAINT_CHARSET specified. Read caveats
306 in automake.in before doing this. Note the same problem used to apply
307 to the no-dependencies option; maybe it still should? Note also that
308 each Makefile.am must be rewritten at "make dist" time if
309 MAINT_CHARSET and DIST_CHARSET are not identical. NOTE: gettext must
310 arrange for all .po files not to be recoded. In the long term this
311 might be a problem (consider when some systems use Unicode but the
313 MAINT_CHARSET *must* be local to each Makefile.am, to enable
314 merged distributions.
315 DIST_CHARSET must be passed down to subdir makes during a "make dist"
317 Handle dist-zoo. Generally add more DOS support. Maybe run "doschk"
318 (why isn't this merged with "pathchk"?) when doing a dist. Do
319 whatever else François says here...
321 Add support for html via an option. Use texi2html. Use
322 "html_TEXINFOS", and htmldir = .../html. Include html files in
323 distribution. Also allow "html_DATA", for raw .html files.
324 [ when will texinfo directly support html? ]
326 uninstall and pkg-dirs should rm -rf the dir.
328 a potential bug: configure puts "blah.o" into LIBOBJS, thus implying
329 these files can't be de-ansified. Not a problem?
330 [ fix by using ansi2knr wrapper program ]
332 In general most .am files should be merged into automake. For
333 instance all the "clean" targets could be merged by keeping lists of
334 things to be removed. This would be a lot nicer looking. Note that
335 the install targets probably should not be merged; it is sometimes
336 useful to only install a small part.
339 * Order rules sensibly
340 * Ensure every line has a purpose. Omit unused stuff
341 * Eliminate extraneous rules when possible (eg 'install-am' stuff)
342 * Make sure vertical spacing is correct
343 Omit program transform vars from header if no program installed. This
344 is currently pretty hard to do. (But with beautification code it
345 would probably be easy)
348 * It would be nice to automatically support using bison's better features
349 to rename the output files. This requires autoconf support
350 * Consider supporting syntax from autoconf "derived:source", eg:
352 for yacc and lex source
353 * what if you use flex and the option to avoid -lfl?
356 Multi-language support:
357 * should have mapping of file extensions to languages
358 * should automatically handle the linking issue (special-case C++)
359 * must get compile rules for various languages; FORTRAN probably
360 most important unimplemented language
361 This should be integrated in some way with Per's idea.
362 Eg .f.o rules should be recognized & auto-handled in _SOURCES
363 That way any random language can be treated with C/C++ on a first-class
366 It might be cool to generate .texi dependencies by grepping for
367 @include. (If done, it should be done the same way C dependencies are
370 It would be good to check some parts of GNU standards. Already check
371 for install-sh and mkinstalldirs. What else is required to be in
372 package by GNU standards or by automake?
373 Some things for --strictness=gnits:
374 * "cd $(foo); something" is an error in a rule. Should be:
375 "cd $(foo) && something"
376 * Look for 'ln -s' and warn about using $(LN) and AC_PROG_LN_S
377 * Look for $(LN) and require AC_PROG_LN_S
379 Auto-distribute "ChangeLog.[0-9]+"? "ChangeLog.[a-z]+"?
381 Internationalize. [ gettext doesn't have the necessary machinery yet ]
382 am_error should use printf-style arguments (for eventual gettext scheme)
384 François says the ordering of files in a distribution should be as follows:
388 I agree, but I don't see how to implement this yet.
389 It might be easier if "derived files" is limited to those that
390 Automake itself knows about, eg output of yacc.
392 Check all source files to make sure that FSF address is up-to-date.
393 --gnits or --gnu only.
395 Merge each -vars.am file with corresponding ".am" file. Can do this
396 because of changes to &file_contents.
398 Should libexec programs have the name transform done on them?
400 Order the output rules sensibly, so FOO_SOURCES and FOO_OBJECTS are
401 together and rules are in the usual order.
403 Make the output minimal: only output definitions for variables that
407 David> To avoid comments like the one about subdirs getting buried in
408 David> the middle of a Makefile.in, how about pushing comments that
409 David> start with ### to the top of the Makefile.in (in order)? Sort
410 David> of like how Autoconf uses diversions to force initialization
411 David> code to the top of configure.
414 Karl> 2) Your Makefile variable names are generally uppercase, but GNU
415 Karl> generally uses lowercase. Not that it matters :-).
417 ================================================================
421 probably should put each group of m4 files into a subdir owned by the
422 containing application.
424 ================================================================
430 how to use the generated makefiles
433 - NORMAL_INSTALL junk
435 what goes in AC_CONFIG_AUX_DIR
437 multi-":" mode in AC_OUTPUT -- automake only looks at the first file
438 also a note on how a .am file is found in this case
440 rationale for avoiding
441 make CFLAGS="$CFLAGS" ...
444 a package that installs its own aclocal macros
446 write example of using automake with dejagnu
447 follow calc example in dejagnu docs
449 document which variables are actually scanned and which are not.
451 Document customary ordering of Makefile.am. From François.
453 Should include extended version of diagram from Autoconf (suggested by
456 Make a definition of the term "source"
458 document how to use Automake with CVS. Idea from Mark Galassi. Also
459 include Greg Woods' more sophisticated "cvs-dist" target.
461 document rebuilding configure. CONFIGURE_DEPENDENCIES
462 CONFIG_STATUS_DEPENDENCIES
464 -- must document all variables that are supposed
465 to be public knowledge
467 must document the targets required for integration with
468 non-automake-using subdirs
470 document the "make SHELL='/bin/sh -x'" trick for debugging
472 section on relationship to GNU make. include notes on parallel makes
476 move discussion of cygwin32, etags, mkid under other gnu tools
478 ================================================================
480 Things to do for autoconf:
482 * patch autoreconf to run automake and aclocal. I've done this but it is
483 not really available. It can't be made available until automake
484 is officially released
486 ================================================================
490 * Should support standalone library along with subdir library in same
491 Makefile.am. Maybe: turn off "standalone" mode if library's Makefile.am
492 is not only one specd? [ add an option for this ]
494 ================================================================
498 Would it be useful to integrate in some way with the Debian package
499 building utility? Must check. maybe it would be possible to deal
500 with all the different package utilities somehow. Lately I've been
501 hearing good things about the RedHat packaging utilities. Why are
502 there so many of these? Are they fun to write or something?
503 The RedHat package utility is called RPM; see
504 ftp://ftp.redhat.com/pub/code/rpm
505 It actually has problems, like no configure script and no documentation.
507 For Cygnus it would probably be good to be able to handle the native
508 package utility on each platform. There are probably 3 or 4 of these
509 (sysv, solaris?, aix?)
511 tcl/unix/Makefile.in has some code to generate a Solaris package.
513 Automake probably can't do all of this on its own. A new tool might
516 I have some notes from a Debian developer on how the integration
519 ================================================================
521 A tool to guess what the local Makefile.am should look like:
522 (see Gord's Maint program!)
524 * Probably integrate with autoscan
525 * Use various simple rules to determine what to do:
526 * get name of top directory, sans version info
527 * search for .c files with 'main' in them
528 * if in main.c, use directory name for program
529 * if in more than one, generate multiple programs
530 * if not found, generate a library named after directory
531 * order subdir searches correctly: lib first, src last
532 * assume 'testsuite' dir means we are using dejagnu
533 * maybe be smart about reading existing Makefile.am, so tool
534 can be run for incremental changes? You could imagine:
537 autoproject --incremental
539 ================================================================
541 Stuff NOT to do, and why:
543 consider auto-including any file that matches "*.in".
544 [ no: po/Makefile.in shouldn't be included ]
546 must look at mkid to see how it works (for subdir usage)
547 [ right now, it doesn't. i don't see a simple fix right now ]
549 if configure.in not found, move up a directory and try again? This
550 could eliminate a common source of problems.
551 [ this is just a bad idea ]
553 * scripts are installed in $exec_prefix/bin, not $prefix/bin
555 [ the consensus on Gnits is that this isn't required.
556 doubters can work around it anyway ]
558 * make the auto-dep code crash if GNU make not in use?
559 (doesn't it already?)
561 Looked at a program called 'ezmake', which seems to do something
562 similar. The only idea there that is possibly worth stealing is using
563 globs in definitions. Also has negations. Eg in a directory with
564 files a.c, b.c and c.c, the line:
565 foo_SOURCES = *.c ~c.c
566 would be equivalent to:
567 foo_SOURCES = a.c b.c
568 Is this worth implementing?
569 [ No... it is more reliable to spell everything out. ]
571 Scan source directories and warn about missing files, eg .c/.h files
572 that aren't mentioned?
573 [ distcheck makes this less useful ]