kmx git

Top priorities:
* Fix up how 'clean' interacts with new naming scheme.

uninstall and pkg-dirs should rm -rf the dir.

Clean up the output:
* Order rules sensibly
* Ensure every line has a purpose.  Omit unused stuff
* Eliminate extraneous rules when possible (eg 'install-am' stuff)
* Make sure vertical spacing is correct
* pretty-print targets, rules, etc.

Need OTHER_SOURCES to hold sources whose objects end up in eg LIBOBJS.
Dependency tracking should work here.

"@kr@" is a hack that should be fixed.  And it should be possible to
have ansi2knr in just one place in a package.

Consider automatic support for ".y" files.  At the very least arrange
to have the corresponding ".c" file be distributed.

Implement better rule for copying through comments.  Rule should be
that if comment immediately precedes rule or variable definition, then
comment should be put there.  Else what happens now is ok.

install-info doesn't have to look in build directory for info files;
just don't support this mode.

Write autoconf macro to do all work necessary for automake.  Eg define
PACKAGE, VERSION, etc.

Change glob pattern to look for to '*/Makefile*.am', so that gettext's
po directory can use a Makefile.in.am (and generate Makefile.in.in)

Should 'distclean' remove $(SCRIPTS)?
Should 'maintainer-clean' do "rm -rf .deps"?
Should look for clean-local targets in Makefile.am.

Consider a --install-missing option to install missing files such as
mdate-sh, texinfo.tex, etc.

Think about writing a small tool to guess what the local Makefile.am
should look like.

Prettyprint macro definitions, eg:
	DIST_COMMON = Makefile.in Makefile.am \
	foo bar baz

It might be cool to generate .texi dependencies by grepping for
@include.  (If done, it should be done the same way C dependency is
done)

Rename --include-deps to --insert-deps?

Merge common parts of "dist" targets into dist-local.

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"

Maybe it should be possible to disable all GNU-specific things with
--no-gnu? --ignore-standards?  But what?  And why?

Allow ".h" files to appear in blah_SOURCES; just write them out of
existence.  [ This is nixed for now because of the auto-dependency
tracking stuff ]

automake.in: should ".cc" really -> ".${kr}o"?  This doesn't really
seem right, but maybe it is so names can be rewritten uniformly?  Must
check

look in configure.in's AC_OUTPUT command and include those files in
distribution.  Or consider new CONFIGURED_FILES macro that lists files
generated by config.status.

Auto-distribute "ChangeLog.[0-9]+"?

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 ]

Internationalize. [ gettext doesn't have the necessary machinery yet ]

================================================================

For CONFIG_HEADER,
  automatically add its input file to the distribution.

Don't hardcode the name of the configuration header.  Get it from
configure.in (AC_CONFIG_HEADER).  

Get the list of Makefiles to create from configure.in AC_OUTPUT
if none are given.
	[ right now we look for any Makefile.am's lying around
	  I think this is better, because it allows use of subdirs
	  which don't use automake -- eg, stuff from gettext ]

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.

Make the output minimal: only output definitions for variables that
are used.

Look at dist's jmake for ideas.  [what is this?]

Should handle directory hierarchies deeper than 2.  Right now there is
no support for this at all.

================================================================

Known Bugs:

version.texi handling is broken -- it assumes you only have one .texi
file per directory.
   (*) In any case, the UPDATED information would be different for
   each .texi file included in a package -- that is my problem.
   Now, if no package will ever have more than one .texi file
   (in a given directory), I can just stop worrying about it.

If there is ever more than one, we will need to change the name of
'version.texi' to be based on the name of the primary .texi file.
Will have to be careful here not to violate MS-DOS name limits.  Also
will need more than one stamp-vti.

[ actually, we could just number them.  version0.texi, version1.texi,
etc ] [ actually, we can't, because the user could be reasonably
expected to want to make dependencies using the name of the .texi file
]

================================================================

Document:


Defined variables, their meanings, and their effects:

DEFS           cpp definitions
INCLUDES       -I options to cpp
CPPFLAGS       more cpp flags
CFLAGS         flags to cc
COMPILE	       how to compile a C program
LINK           how to link a C program

DIST_SUBDIRS   directories which are copied verbatim into the
               distribution.  Used eg for directories holding
               only example code (which don't have their own
               makefile).  This variable might be a bad idea.

lib_LIBADD	code conditionally included in a library
		This probably needs to be redone anyway.

AM_TEXINFOS	override form
SUFFIXES	additional suffixes

Document customary ordering of Makefile.am.  From Franc,ois.

Automake assumes SCRIPTS are built from something else.  They are
removed during 'make clean'.  Beware.

================================================================

Libraries:

X Need a way to specify library should be installed
* 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?
X Need a way to install library header files.
* Need a way to handle shared libraries.
  It would be really interesting to be able to easily (as the end-user)
  make many different versions of the library: shared, static, profiling,
  debug, optimized...
X Must ranlib libraries after installing

Some examples to keep in mind while doing this:
* readline
* kpathsea

================================================================

Have a program that generates a Makefile on stdout, passes it through
a "config.status" style filter, and thence into make.  Why bother,
other than the gee-whiz factor?

Would it be useful to integrate in some way with the Debian package
building utility?  Must check.
kc3-lang/automake/TODO

Commit

TODO
