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