automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FYI: some typos


From: Alexandre Duret-Lutz
Subject: FYI: some typos
Date: Sun, 14 Mar 2004 08:26:39 +0100
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux)

Installed on HEAD and branch-1-8.

2004-03-14  Alexandre Duret-Lutz  <address@hidden>

        * automake.in (handle_texinfo_helper): Typos in comment.

Index: automake.in
===================================================================
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.1526.2.8
diff -u -r1.1526.2.8 automake.in
--- automake.in 29 Feb 2004 19:10:40 -0000      1.1526.2.8
+++ automake.in 14 Mar 2004 07:25:01 -0000
@@ -2822,11 +2822,11 @@
       #       because `make dist' always pick files in the build tree
       #       first.
       # However it turned out the be a bad idea for several reasons:
-      #   * Tru64, OpenBSD, and FreeBSD (not NetBSD) Make do behave
+      #   * Tru64, OpenBSD, and FreeBSD (not NetBSD) Make do not behave
       #     like GNU Make on point (1) above.  These implementations
       #     of Make would always rebuild .info files in the build
       #     tree, even if such files were up to date in the source
-      #     tree.  Consequently, it was impossible the perform a VPATH
+      #     tree.  Consequently, it was impossible to perform a VPATH
       #     build of a package containing Texinfo files using these
       #     Make implementations.
       #     (Refer to the Autoconf Manual, section "Limitation of
@@ -2839,7 +2839,7 @@
       #     build tree can be annoying during development because
       #     - if the files is kept under CVS, you really want it
       #       to be updated in the source tree
-      #     - it os confusing that `make distclean' does not erase
+      #     - it is confusing that `make distclean' does not erase
       #       all files in the build tree.
       #
       # Consequently, starting with Automake 1.8, .info files are

-- 
Alexandre Duret-Lutz





reply via email to

[Prev in Thread] Current Thread [Next in Thread]