[Automake-commit] [SCM] GNU Automake branch, master, updated. v1.11-2095-g8cbbdb8

[Stefano Lattarini]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU Automake".

http://git.sv.gnu.org/gitweb/?p=automake.git;a=commitdiff;h=8cbbdb8790d5eb24bb813edb27ecaf9807676890

The branch, master has been updated
       via  8cbbdb8790d5eb24bb813edb27ecaf9807676890 (commit)
      from  4586d24dc7598c177939df2db65e1b0cbc060757 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 8cbbdb8790d5eb24bb813edb27ecaf9807676890
Author: Stefano Lattarini <address@hidden>
Date:   Fri Mar 23 09:13:11 2012 +0100

    maint: update TODO file
    
    We don't have to make creation of $(foodir) conditional when
    foo_PRIMARY is conditionally defined; that has been solved in
    a more sweeping way by commit v1.11-759-g368f1c4 of March 18,
    which solved bug#11030 and bug#10997.
    
    The "check" target already depends on the "all" target.
    
    Remove comment "investigate problems with conditionally defined
    libraries"; it is aimed at automake 1.5 (!) and too terse and old
    to be useful now.
    
    Remove the 12 years old suggestion that "distcheck should make sure
    that each file that uses _() is listed in POTFILES.in"; this is
    handled by gnulib-provided syntax check 'sc_po_check' already today.
    
    Don't tell to "Run automake before libtool"; automake does not
    automatically run libtool anymore today.
    
    Remove hint about the possibility to "rewrite automake in guile" or
    "add a GUI": we are not going to do so.
    
    The automatic de-ANSI-fication feature has already been remove, so
    no need to suggest its potential removal in the future.
    
    Remove reference to a prospective "cvs" option that could add some
    cvs-specific rules.  First of all, CVS is falling out of use today.
    Secondly, and most to the point, instead of guessing which VCS
    is going to be most popular and try to hack support for it into
    automake, we should leave it to developer-specific makefile
    fragments offered by projects like Gnulib to provide such rules
    (they are already doing so with succcess).
    
    About DOS support: it should actually be dropped, not extended.
    
    Add link about Karl Berry's proposal of preferring HTML over Info
    documentation installed in the local system:
    <http://lists.gnu.org/archive/html/texinfo-devel/2012-03/msg00018.html>
    
    Remove items about "beautification" of output Makefile.in; they
    are pretty obvious, and mostly noise (after all, everybody prefers
    clean output where possible).  Leave it to any developer doing
    future refactorings to find out low-hanging and/or high-impact
    optimizations and beatifications of the generated Makefiles.
    
    Remove item about internationalization: we're not going to
    implement it.
    
    Remove an item explicitly marked as "not that it matters".
    
    The order of files in a distribution tarball does not really
    matter, nobody has ever complained about it, so do not worry
    about it.
    
    Remove the suggestions about allowing hierarchy of dirs to share
    one aclocal.m4 and about printing full file name of Makefile.am
    or configure.in when giving error, in order to help very large
    trees: nobody has ever complained about the current behaviours,
    so no real need to change them.
    
    Signed-off-by: Stefano Lattarini <address@hidden>

-----------------------------------------------------------------------

Summary of changes:
 TODO |   83 ++---------------------------------------------------------------
 1 files changed, 3 insertions(+), 80 deletions(-)

diff --git a/TODO b/TODO
index 8ad887f..f8e4754 100644
--- a/TODO
+++ b/TODO
@@ -1,12 +1,3 @@
-We should arrange so that install-%DIR%%PRIMARY% is run conditionally
-when %DIR%_%PRIMARY% is defined conditionally.  Currently it is always
-run, and that will therefore always create %DIR% (unless %DIR%dir is
-also defined conditionally).  Likewise, installdirs should not
-create %DIR% in conditions were no %DIR%_%PRIMARY% is enabled.
-
-check should depend on all
-  from ben elliston
-
 the new YFLAGS code doesn't correctly handle srcdir
 
 allow foo_NAME to rename an object (library or program)
@@ -15,9 +6,6 @@ at build/install time
 remove _LTLIBRARIES and just use _LIBRARIES
 then use this for zip/jar as well
 
-for 1.5
-investigate problems with conditionally defined libraries
-
 add an error if the user makefile.am violates our
    namespace rules
 
@@ -86,16 +74,6 @@ Alex Hornby
     unfortunately it isn't that useful until autoconf has support
     for this sort of thing as well ]
 
-* distcheck should make sure that each file that uses _() is
-  listed in POTFILES.in
-  From Jim Meyering:
-    # Verify that all source files using _() are listed in po/POTFILES.in.
-    po-check:
-           grep -E -v '^(#|$$)' po/POTFILES.in | sort > address@hidden
-           grep -E -l '\b_\(' lib/*.c src/*.c | sort > address@hidden
-           diff -u address@hidden address@hidden
-           rm -f address@hidden address@hidden
-
 * one performance enhancement would be to have autoconf write
   a single file containing all the macro assignments.
   then read this file via `include'
@@ -123,10 +101,6 @@ Alex Hornby
   If you are building a compiled Java library, then the .zip/.jar
   ought to be made automatically.
 
-* Run automake before libtool.  It will report an error but
-  still won't put the file into the disty.  This is wrong.
-  From Mark H Wilkinson <address@hidden>
-
 * examine possibility of using any character in a macro name
   and rewriting names automatically.  this means we must rewrite
   all references as well.
@@ -183,11 +157,6 @@ Alex Hornby
 * For now I guess I'll just have automake give an error if it encounters
 non-C source in a libtool library specification.
 
-* must split $obj into two parts: one for libtool and one for
-  deansification.  Otherwise .S files will be deansified!
-
-* ansi2knr must currently appear in a directory that has some source
-
 * 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
@@ -197,12 +166,6 @@ non-C source in a libtool library specification.
   strictness should only cover requirements
   You should be able to pick and choose options
 
-* rewrite in guile (RMS request)
-at the same time, consider adding a GUI
-could use the same parsing code for the GUI and the standalone version
-that means figuring out a better representation of internal state
-[ that's easy -- anything is better than what we have now ]
-
 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
@@ -259,14 +222,6 @@ from joerg-martin schwarz:
     in an explicitly written rule,  you should emit the corresponding
     Makefile variables automatically.
 
-Configuring in the large:
-* allow hierarchy of dirs to share one aclocal.m4
-  How?
-
-consider printing full file name of Makefile.am or configure.in when
-giving error.  This would help for very large trees with many
-configure.in scripts
-
 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
@@ -276,15 +231,11 @@ 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.
-* standards no longer prohibit ANSI C.  What does this imply
-  for the de-ansi-fication feature? [ must keep it -- some users rely on it ]
 
 should be able to determine what is built by looking at rules (and
 configure.in).  Then built man pages (eg) could automatically be
 omitted from the distribution.
 
-Consider: "cvs" option adds some cvs-specific rules?
-
 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
@@ -309,14 +260,13 @@ Need way to say there are no suffixes in a Makefile 
(Franc,ois'
 Check to make sure various scripts are executable (IE when looking for
 them in a directory)
 
-Handle dist-zoo.  Generally add more DOS support.  Maybe run "doschk"
-(why isn't this merged with "pathchk"?) when doing a dist.  Do
-whatever else François says here...
-
 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.
 
@@ -326,15 +276,6 @@ 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.
 
-* 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
-Omit program transform vars from header if no program installed.  This
-is currently pretty hard to do.  (But with beautification code it
-would probably be easy)
-
 * Lex, yacc support:
 ** It would be nice to automatically support using bison's better features
   to rename the output files.  This requires autoconf support
@@ -370,17 +311,6 @@ Some things for --strictness=gnits:
 
 Auto-distribute "ChangeLog.[0-9]+"?  "ChangeLog.[a-z]+"?
 
-Internationalize. [ gettext doesn't have the necessary machinery yet ]
-am_error should use printf-style arguments (for eventual gettext scheme)
-
-François says the ordering of files in a distribution should be as follows:
-* README
-* source files
-* derived files
-I agree, but I don't see how to implement this yet.
-It might be easier if "derived files" is limited to those that
-Automake itself knows about, eg output of yacc.
-
 Check all source files to make sure that FSF address is up-to-date.
 --gnits or --gnu only.
 
@@ -392,9 +322,6 @@ 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.
-
 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
@@ -402,10 +329,6 @@ 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.
 
-Karl Berry says:
-Karl> 2) Your Makefile variable names are generally uppercase, but GNU
-Karl> generally uses lowercase. Not that it matters :-).
-
 ================================================================
 
 Stuff for aclocal:


hooks/post-receive
-- 
GNU Automake