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