#!/bin/sh
# Get modification time of a file or directory and pretty-print it.
-scriptversion=2009-04-28.21; # UTC
+scriptversion=2010-02-22.21; # UTC
-# Copyright (C) 1995, 1996, 1997, 2003, 2004, 2005, 2007, 2009 Free
-# Software Foundation, Inc.
+# Copyright (C) 1995, 1996, 1997, 2003, 2004, 2005, 2007, 2009, 2010
+# Free Software Foundation, Inc.
# written by Ulrich Drepper <drepper@gnu.ai.mit.edu>, June 1995
#
# This program is free software; you can redistribute it and/or modify
cat <<\EOF
Usage: mdate-sh [--help] [--version] FILE
-Pretty-print the modification time of FILE.
+Pretty-print the modification day of FILE, in the format:
+1 January 1970
Report bugs to <bug-automake@gnu.org>.
EOF
@node Makefile Conventions
@chapter Makefile Conventions
-@comment standards.texi does not print an index, but make.texinfo does.
@cindex makefile, conventions for
@cindex conventions for makefiles
@cindex standards for makefiles
@node DESTDIR
-@section @code{DESTDIR}: support for staged installs
+@section @code{DESTDIR}: Support for Staged Installs
@vindex DESTDIR
@cindex staged installs
default settings specified here so that all GNU packages behave
identically, allowing the installer to achieve any desired layout.
+@cindex directories, creating installation
+@cindex installation directories, creating
+All installation directories, and their parent directories, should be
+created (if necessary) before they are installed into.
+
These first two variables set the root for the installation. All the
other installation directories should be subdirectories of one of
these two, and nothing should be directly installed into these two
the @code{install-info} program if it is present. @code{install-info}
is a program that edits the Info @file{dir} file to add or update the
menu entry for the given Info file; it is part of the Texinfo package.
-Here is a sample rule to install an Info file:
+
+Here is a sample rule to install an Info file that also tries to
+handle some additional situations, such as @code{install-info} not
+being present.
@comment This example has been carefully formatted for the Make manual.
@comment Please do not reformat it without talking to bug-make@gnu.org.
@smallexample
-$(DESTDIR)$(infodir)/foo.info: foo.info
- $(POST_INSTALL)
-# There may be a newer info file in . than in srcdir.
- -if test -f foo.info; then d=.; \
- else d=$(srcdir); fi; \
- $(INSTALL_DATA) $$d/foo.info $(DESTDIR)$@@; \
+do-install-info: foo.info installdirs
+ $(NORMAL_INSTALL)
+# Prefer an info file in . to one in srcdir.
+ if test -f foo.info; then d=.; \
+ else d="$(srcdir)"; fi; \
+ $(INSTALL_DATA) $$d/foo.info \
+ "$(DESTDIR)$(infodir)/foo.info"
# Run install-info only if it exists.
# Use `if' instead of just prepending `-' to the
# line so we notice real errors from install-info.
-# We use `$(SHELL) -c' because some shells do not
+# Use `$(SHELL) -c' because some shells do not
# fail gracefully when there is an unknown command.
+ $(POST_INSTALL)
if $(SHELL) -c 'install-info --version' \
>/dev/null 2>&1; then \
- install-info --dir-file=$(DESTDIR)$(infodir)/dir \
- $(DESTDIR)$(infodir)/foo.info; \
+ install-info --dir-file="$(DESTDIR)$(infodir)/dir" \
+ "$(DESTDIR)$(infodir)/foo.info"; \
else true; fi
@end smallexample
It's useful to add a target named @samp{installdirs} to create the
directories where files are installed, and their parent directories.
There is a script called @file{mkinstalldirs} which is convenient for
-this; you can find it in the Texinfo package.
-@c It's in /gd/gnu/lib/mkinstalldirs.
+this; you can find it in the Gnulib package.
You can use a rule like this:
@comment This has been carefully formatted to look decent in the Make manual.
@end smallexample
@noindent
-or, if you wish to support @env{DESTDIR},
+or, if you wish to support @env{DESTDIR} (strongly encouraged),
@smallexample
# Make sure all installation directories (e.g. $(bindir))
@setfilename standards.info
@settitle GNU Coding Standards
@c This date is automagically updated when you save this file:
-@set lastupdate December 11, 2009
+@set lastupdate February 17, 2010
@c %**end of header
@dircategory GNU organization
The GNU coding standards, last updated @value{lastupdate}.
Copyright @copyright{} 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 Free Software
+2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software
Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document
GCC developers many hours, or even days, per year.
In the case of function-like macros like @code{REVERSIBLE_CC_MODE} in
-GCC which cannot be simply used in @code{if( ...)} statements, there is
+GCC which cannot be simply used in @code{if (...)} statements, there is
an easy workaround. Simply introduce another macro
@code{HAS_REVERSIBLE_CC_MODE} as in the following example:
avoid this problem by creating temporary files in this manner:
@example
-fd = open(filename, O_WRONLY | O_CREAT | O_EXCL, 0600);
+fd = open (filename, O_WRONLY | O_CREAT | O_EXCL, 0600);
@end example
@noindent
The change log file is normally called @file{ChangeLog} and covers an
entire directory. Each directory can have its own change log, or a
-directory can use the change log of its parent directory--it's up to
+directory can use the change log of its parent directory---it's up to
you.
Another alternative is to record change log information with a version
to a @file{ChangeLog} file using @code{rcs2log}; in Emacs, the command
@kbd{C-x v a} (@code{vc-update-change-log}) does the job.
-There's no need to describe the full purpose of the changes or how they
-work together. If you think that a change calls for explanation, you're
-probably right. Please do explain it---but please put the explanation
-in comments in the code, where people will see it whenever they see the
-code. For example, ``New function'' is enough for the change log when
-you add a function, because there should be a comment before the
-function definition to explain what it does.
+There's no need to describe the full purpose of the changes or how
+they work together. However, sometimes it is useful to write one line
+to describe the overall purpose of a change or a batch of changes. If
+you think that a change calls for explanation, you're probably right.
+Please do explain it---but please put the full explanation in comments
+in the code, where people will see it whenever they see the code. For
+example, ``New function'' is enough for the change log when you add a
+function, because there should be a comment before the function
+definition to explain what it does.
In the past, we recommended not mentioning changes in non-software
files (manuals, help files, etc.) in change logs. However, we've been
advised that it is a good idea to include them, for the sake of
copyright records.
-However, sometimes it is useful to write one line to describe the
-overall purpose of a batch of changes.
-
The easiest way to add an entry to @file{ChangeLog} is with the Emacs
command @kbd{M-x add-change-log-entry}. An entry should have an
asterisk, the name of the changed file, and then in parentheses the name
projects / pspp / commitdiff