Re: [bug-gnulib] use of __gen_tempname
Eric, > > Please apply. I'm sorry that I missed this mail. Something must be wrong with my mailbox. Bruno
coreutils build failure due to missing gl_INLINE dependency
I tried to build coreutils using the very latest from gnulib and got link failures due to missing xcharalloc, used by e.g., quotearg.o. I tracked it back to the lack of a HAVE_INLINE definition in config.h, which in turn was due to a defect in the gnulib xalloc module. It did not arrange to use the gl_INLINE macro that provides HAVE_INLINE. It *did* list m4/inline.m4 as one of its "Files:", but didn't do anything else. Since two other modules (oset and list) also include m4/inline.m4 without a provision to use gl_INLINE, it's clear that it's worthwhile to make a module out of this inline.m4 file, so I did that. But the following patch didn't solve the coreutils build problem, due to a problem with inline.m4 itself. That's the topic of the next message. I've checked in these changes: * modules/inline: New file/module. * modules/xalloc (Files): Remove m4/inline.m4. (Depends-on): Add inline, instead. * modules/oset: Likewise. * modules/list: Likewise. Index: modules/inline === RCS file: modules/inline diff -N modules/inline --- /dev/null 1 Jan 1970 00:00:00 - +++ modules/inline 10 Nov 2006 09:55:44 - @@ -0,0 +1,20 @@ +Description: +Test for the 'inline' keyword or equivalent. + +Files: +m4/inline.m4 + +Depends-on: + +configure.ac: +gl_INLINE + +Makefile.am: + +Include: + +License: +GPL + +Maintainer: +all Index: modules/xalloc === RCS file: /sources/gnulib/gnulib/modules/xalloc,v retrieving revision 1.20 diff -u -r1.20 xalloc --- modules/xalloc 8 Nov 2006 00:22:30 - 1.20 +++ modules/xalloc 10 Nov 2006 09:55:44 - @@ -5,9 +5,9 @@ lib/xalloc.h lib/xmalloc.c m4/xalloc.m4 -m4/inline.m4 Depends-on: +inline xalloc-die configure.ac: Index: modules/oset === RCS file: /sources/gnulib/gnulib/modules/oset,v retrieving revision 1.2 diff -u -r1.2 oset --- modules/oset7 Nov 2006 13:46:03 - 1.2 +++ modules/oset10 Nov 2006 09:55:44 - @@ -5,9 +5,9 @@ lib/gl_oset.h lib/gl_oset.c m4/gl_list.m4 -m4/inline.m4 Depends-on: +inline stdbool configure.ac: @@ -24,4 +24,3 @@ Maintainer: Bruno Haible - Index: modules/list === RCS file: /sources/gnulib/gnulib/modules/list,v retrieving revision 1.2 diff -u -r1.2 list --- modules/list7 Nov 2006 13:46:03 - 1.2 +++ modules/list10 Nov 2006 09:55:44 - @@ -5,9 +5,9 @@ lib/gl_list.h lib/gl_list.c m4/gl_list.m4 -m4/inline.m4 Depends-on: +inline stdbool configure.ac: @@ -24,4 +24,3 @@ Maintainer: Bruno Haible -
inline.m4: use compiler, not cpp
The gl_INLINE macro was failing to define HAVE_INLINE, and that led to link errors when building coreutils with CFLAGS=-O. gl_INLINE used cpp and $CPPFLAGS, and since the latter doesn't include $CFLAGS, it missed the critical -O option. Without -O, gcc *does* define __NO_INLINE__, so HAVE_INLINE was not defined. However, when compiling (with $CFLAGS containing -O), there was no external definition of any function like xnmalloc or xcharalloc. Paul, here's the change I'm using: 2006-11-10 Jim Meyering <[EMAIL PROTECTED]> * m4/inline.m4 (gl_INLINE): Check with the compiler, not cpp, so that relevant options in CFLAGS (like -O, -fno-inline) are taken into account. Index: m4/inline.m4 === RCS file: /sources/gnulib/gnulib/m4/inline.m4,v retrieving revision 1.2 diff -u -r1.2 inline.m4 --- m4/inline.m48 Nov 2006 14:03:04 - 1.2 +++ m4/inline.m410 Nov 2006 11:09:44 - @@ -1,4 +1,4 @@ -# inline.m4 serial 2 +# inline.m4 serial 3 dnl Copyright (C) 2006 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -19,11 +19,13 @@ else dnl GCC defines __NO_INLINE__ if not optimizing or if -fno-inline is dnl specified. - AC_EGREP_CPP([bummer], [ - #ifdef __NO_INLINE__ - bummer - #endif - ], [gl_cv_c_inline_effective=no], [gl_cv_c_inline_effective=yes]) + AC_COMPILE_IFELSE( +[AC_LANG_PROGRAM([[]], + [EMAIL PROTECTED]:@ifdef __NO_INLINE__ + @%:@error "inline is not effective" +@%:@endif]])], +[gl_cv_c_inline_effective=yes], +[gl_cv_c_inline_effective=no]) fi ]) if test $gl_cv_c_inline_effective = yes; then
Re: [bug-gnulib] coreutils build failure due to missing gl_INLINE dependency
Jim Meyering wrote: > Since two other modules (oset and list) also include m4/inline.m4 > without a provision to use gl_INLINE, it's clear that it's worthwhile > to make a module out of this inline.m4 file, so I did that. Thanks!
Re: [bug-gnulib] inline.m4: use compiler, not cpp
Jim Meyering wrote: > 2006-11-10 Jim Meyering <[EMAIL PROTECTED]> > > * m4/inline.m4 (gl_INLINE): Check with the compiler, not cpp, > so that relevant options in CFLAGS (like -O, -fno-inline) are > taken into account. Thanks again! I applied this patch, with added comments, and without the quadrigraphs for '#'. (It works with '#' therefore why write '@%:@'?) > The gl_INLINE macro was failing to define HAVE_INLINE, > and that led to link errors when building coreutils with CFLAGS=-O. Hmm. I understand such link errors if, after updating from gnulib, you did "make" without "make clean". If you got the link errors also after doing a "make clean; make", there must still be an error somewhere. The HAVE_INLINE is only a hint. Do you still get a link error when configuring and compiling with no optimization (CFLAGS empty)? Bruno
Re: [bug-gnulib] lib/gettext.h breaks --enable-gcc-warnings
Paul Eggert wrote: > 2006-11-09 Paul Eggert <[EMAIL PROTECTED]> > > * lib/gettext.h (dgettext, dcgettext, ngettext) [! ENABLE_NLS]: > (dngettext, dcngettext, bindtextdomain) [! ENABLE_NLS]: > (bind_textdomain_codeset) [! ENABLE_NLS]: > Evaluate all the arguments. That way, callers get compatible > behavior if the arguments have side effects. Also, it avoids > some GCC diagnostics in some cases; Joel E. Denny reported problems > when > Bison was configured with --enable-gcc-warnigs. Thanks, applied in gnulib and GNU gettext. Bruno
Re: inline.m4: use compiler, not cpp
Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> 2006-11-10 Jim Meyering <[EMAIL PROTECTED]> >> >> * m4/inline.m4 (gl_INLINE): Check with the compiler, not cpp, >> so that relevant options in CFLAGS (like -O, -fno-inline) are >> taken into account. > > Thanks again! I applied this patch, with added comments, and without > the quadrigraphs for '#'. (It works with '#' therefore why write '@%:@'?) Indeed. Better not to blindly follow old examples :-) >> The gl_INLINE macro was failing to define HAVE_INLINE, >> and that led to link errors when building coreutils with CFLAGS=-O. > > Hmm. I understand such link errors if, after updating from gnulib, you > did "make" without "make clean". If you got the link errors also after doing > a "make clean; make", there must still be an error somewhere. The HAVE_INLINE > is only a hint. Do you still get a link error when configuring and compiling > with no optimization (CFLAGS empty)? I did not run "make clean", but did ensure that config.h was updated. That alone should have caused all "old" .o files to be rebuilt, but there is a bug (haven't investigated at all yet) whereby most of the generated dependencies (lib/.deps/*.Po files) are not included into the Makefile.
Re: inline.m4: use compiler, not cpp
Hello Jim, * Jim Meyering wrote on Fri, Nov 10, 2006 at 03:53:42PM CET: > > I did not run "make clean", but did ensure that config.h was updated. > That alone should have caused all "old" .o files to be rebuilt, but there > is a bug (haven't investigated at all yet) whereby most of the generated > dependencies (lib/.deps/*.Po files) are not included into the Makefile. http://lists.gnu.org/archive/html/bug-automake/2006-11/msg00013.html Cheers, Ralf
Re: [bug-gnulib] yet another hello pretest
Paul Eggert wrote: > 2. The "#if ENABLE_NLS" isn't needed, since gettext.h does the right > thing anyway. > -#if ENABLE_NLS >/* Set the text message domain. */ >bindtextdomain (PACKAGE, LOCALEDIR); >textdomain (PACKAGE); > -#endif But with this, configuring with "./configure --disable-nls CPPFLAGS=-Wall", I get warnings: hello.c: In function 'main': hello.c:53: warning: statement with no effect hello.c:54: warning: statement with no effect So, either add casts to void: /* Set the text message domain. */ (void) bindtextdomain (PACKAGE, LOCALEDIR); (void) textdomain (PACKAGE); or add back the #if ENABLE_NLS. Since these (void) casts make the code look ancient and are not very understandable, my preferrence is for the #if ENABLE_NLS - it's clear what it means. Bruno
Re: proposed patch to allocsa, vasnprintf for Tandem NSK (OSS)
Paul Eggert wrote: Matthew Woehlke writes: Actually, while trying to compile m4, it looks like this may indeed be a problem. OSS's sys/stat.h bombs if int64_t is not defined, Can you please explain exactly why this problem occurs? gnulib's stdint.h replacement should include the relevant system include files, and if they define int64_t then gnulib's stdint.h should do so as well. AFAICT it isn't, /right now/. It sounded like your comment was talking about removing 64-bit int support altogether, which I was noting out might have obscure repercussions (on top of this situation being obscure to begin with :-)). If I am confused, then you can ignore me. :-) -- Matthew "You're older than you've ever been / And now you're even older" -- They Might Be Giants
missing dependencies [Re: inline.m4: use compiler, not cpp
Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello Jim, > > * Jim Meyering wrote on Fri, Nov 10, 2006 at 03:53:42PM CET: >> >> I did not run "make clean", but did ensure that config.h was updated. >> That alone should have caused all "old" .o files to be rebuilt, but there >> is a bug (haven't investigated at all yet) whereby most of the generated >> dependencies (lib/.deps/*.Po files) are not included into the Makefile. > > http://lists.gnu.org/archive/html/bug-automake/2006-11/msg00013.html Hi Ralf, Humph! :-) It sounds like the recent trend to remove uses of AC_LIBSOURCE (in favor of listing source file names in each module-file Files: section) is the reason for at least some of my missing dependencies. If so, that is a very undesirable (and unintended, I'm sure) side effect. I can't be the only one bothered by this... CPU cycles aren't *that* cheap. Having to remember to "make clean" all the time is so archaic/dangerous/wasteful -- reminiscent of the old days, back before we had reliable automatic dependency generation. I hope someone finds the time to bell this cat soon!
Re: yet another hello pretest
Bruno Haible <[EMAIL PROTECTED]> wrote: > Paul Eggert wrote: >> 2. The "#if ENABLE_NLS" isn't needed, since gettext.h does the right >> thing anyway. > >> -#if ENABLE_NLS >>/* Set the text message domain. */ >>bindtextdomain (PACKAGE, LOCALEDIR); >>textdomain (PACKAGE); >> -#endif > > But with this, configuring with "./configure --disable-nls CPPFLAGS=-Wall", > I get warnings: > > hello.c: In function 'main': > hello.c:53: warning: statement with no effect > hello.c:54: warning: statement with no effect > > So, either add casts to void: > > /* Set the text message domain. */ > (void) bindtextdomain (PACKAGE, LOCALEDIR); > (void) textdomain (PACKAGE); > > or add back the #if ENABLE_NLS. > > Since these (void) casts make the code look ancient and are not very > understandable, my preferrence is for the #if ENABLE_NLS - it's clear > what it means. Better still, add this in system.h: #if ! ENABLE_NLS # undef textdomain # define textdomain(Domainname) /* empty */ # undef bindtextdomain # define bindtextdomain(Domainname, Dirname) /* empty */ #endif Then your function body isn't "dirtied" with #if directives, the *textdomain functions are defined away, and you don't need the anachronistic-looking (void) casts. 2006-11-10 Jim Meyering <[EMAIL PROTECTED]> * system.h: Avoid warnings when configured with "./configure --disable-nls CFLAGS=-Wall". Reported by Bruno Haible. Index: src/system.h === RCS file: /sources/hello/hello/src/system.h,v retrieving revision 1.5 diff -u -r1.5 system.h --- src/system.h23 Aug 2006 13:55:15 - 1.5 +++ src/system.h10 Nov 2006 16:08:04 - @@ -34,6 +34,13 @@ #define _(str) gettext (str) #define N_(str) gettext_noop (str) +#if ! ENABLE_NLS +# undef textdomain +# define textdomain(Domainname) /* empty */ +# undef bindtextdomain +# define bindtextdomain(Domainname, Dirname) /* empty */ +#endif + /* Check for errors on write. */ #include "closeout.h"
Re: stdint_.h incorrectly assumes unsigned of 'int64_t'
Paul Eggert wrote: Matthew Woehlke <[EMAIL PROTECTED]> writes: ...which I assume those who have been following my NSK woes will immediately spot the flaw in? :-) Thanks, I installed this patch into gnulib: [patch snipped] That looks good, thanks! (This was stdint_.h from coreutils-6.4, IIRC someone had said that should be more recent than patches that went in for NSK? gnulib has the most-recent copy. Right, what I meant was to my knowledge no NSK-related patches went into GNUlib after what 6.4 pulled in. I think that if you want to continue the porting effort we (by which I mean, mostly, _you_ :-) should probably just come up with the patches that work for you, and we can worry about integrating them into the upstream version later. That's fine, as long the people that know the code much better than I are still willing to offer advice. You just usually beat me to patches. :-) (In this case, I thought the patch was both obvious and trivial, and apparently I was right. :-)) Although to be honest, I'm also hoping that the end is in sight. Already, thanks to your wonderful support so far, I am much further along in establishing a modern (and mostly-OOTB) GNU toolchain than before. The simplest thing for you may be to upgrade to Tandem's current compiler, which doesn't seem to have these problems. I'm not sure if that's an option, given that I don't have control over the machine. I have admin access so I can install software that I have, but I don't know that I can get software from HP (and more importantly, *without paying for it*), or that people would appreciate something as drastic as upgrading the compiler. If I get a chance, I'll keep in mind to bring this up, but I'm not optimistic. -- Matthew "You're older than you've ever been / And now you're even older" -- They Might Be Giants
Re: missing dependencies [Re: inline.m4: use compiler, not cpp
Jim Meyering wrote: > >> but there > >> is a bug (haven't investigated at all yet) whereby most of the generated > >> dependencies (lib/.deps/*.Po files) are not included into the Makefile. I agree with Ralf that it's most likely tied to the issue I reported two days ago: In summary (thanks Ralf for the insights), Automake's dependency mechanism doesn't work for object files added to lib..._LIBADD and lib..._DEPENDENCIES. > I hope someone finds the time to bell this cat soon! I'll try to find a workaround in gnulib. Bruno
Re: yet another hello pretest
Jim Meyering wrote: > Better still, add this in system.h: > > #if ! ENABLE_NLS > # undef textdomain > # define textdomain(Domainname) /* empty */ > # undef bindtextdomain > # define bindtextdomain(Domainname, Dirname) /* empty */ > #endif If you do this, you'll get "unused variable" warnings when you use textdomain or bindtextdomain with non-literal arguments. It might work in your system.h, but is IMO not suitable for general use in gettext.h. Bruno
Re: yet another hello pretest
Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> Better still, add this in system.h: >> >> #if ! ENABLE_NLS >> # undef textdomain >> # define textdomain(Domainname) /* empty */ >> # undef bindtextdomain >> # define bindtextdomain(Domainname, Dirname) /* empty */ >> #endif > > If you do this, you'll get "unused variable" warnings when you use > textdomain or bindtextdomain with non-literal arguments. It might work > in your system.h, but is IMO not suitable for general use in gettext.h. Hi Bruno, You seem to have misunderstood. It sounds like you're objecting to something, but I didn't propose to put it in *gettext.h*. I don't see how you could be objecting to such an addition to hello's system.h. If someone is doing something fancy, they can be expected to find their own solution. GNU hello is about demonstrating what works for most packages. The above works for all 90+ programs in the coreutils package, as well as for many other GNU tools.
Re: yet another hello pretest
Jim, > I don't see > how you could be objecting to such an addition to hello's system.h. It's up to Karl to decide what he puts into hello's system.h. I only mentioned that these definitions can _in_general_ lead to "unused variable" warnings. Bruno
Re: gnulib-tool --with-tests --test
* Ralf Wildenhues wrote on Thu, Nov 09, 2006 at 12:12:27AM CET:
> It would be nice if
> gnulib-tool --with-tests --test
>
> succeeded out of the box, including actually running the tests.
The patch below should some of the reported issues. OK to apply?
FWIW, I still don't understand the necessity of a separate configure
script in the gltests/ subdirectory at all. Is that just for testing
purposes?
Cheers,
Ralf
2006-11-10 Ralf Wildenhues <[EMAIL PROTECTED]>
* gnulib-tool (func_create_testdir): Fix gl_source_base setting.
Fix replacement of `build-aux' in configure.ac.
Run autotools in gltests subdirectory.
(func_create_testdir, func_create_megatestdir, test): There is
no need for '--force' in most autotool invocations in a new
tree. Actually fail the whole test if any of the tools, or the
configure or make stages fail.
Index: gnulib-tool
===
RCS file: /cvsroot/gnulib/gnulib/gnulib-tool,v
retrieving revision 1.188
diff -u -r1.188 gnulib-tool
--- gnulib-tool 6 Nov 2006 13:04:37 - 1.188
+++ gnulib-tool 10 Nov 2006 17:38:45 -
@@ -2284,7 +2284,7 @@
echo "gl_libdeps="
echo "gl_ltlibdeps="
fi
- echo "gl_source_base='$testsbase'"
+ echo "gl_source_base='../$sourcebase'"
# Wrap the set of autoconf snippets into an autoconf macro that is then
# invoked. This is needed because autoconf does not support AC_REQUIRE
# at the top level:
@@ -2294,17 +2294,13 @@
# expansion total).
echo "AC_DEFUN([gl_INIT], ["
func_emit_initmacro_start
- if test "$auxdir" != "build-aux"; then
- sed_replace_build_aux='
- :a
- /AC_CONFIG_FILES(.*:build-aux\/.*)/{
-
s|AC_CONFIG_FILES(\(.*\):build-aux/\(.*\))|AC_CONFIG_FILES(\1:../'"$auxdir"'/\2)|
- ba
- }'
- sed_replace_build_aux=`echo "$sed_replace_build_aux" | sed -e 1d -e
's/^ *//'`
- else
- sed_replace_build_aux=
- fi
+ sed_replace_build_aux='
+ :a
+ /AC_CONFIG_FILES(.*:build-aux\/.*)/{
+
s|AC_CONFIG_FILES(\(.*\):build-aux/\(.*\))|AC_CONFIG_FILES(\1:../'"$auxdir"'/\2)|
+ba
+ }'
+ sed_replace_build_aux=`echo "$sed_replace_build_aux" | sed -e 1d -e 's/^
*//'`
# We don't have explicit ordering constraints between the various
# autoconf snippets. It's cleanest to put those of the library before
# those of the tests.
@@ -2463,33 +2459,57 @@
# autopoint, which brings in older versions of some of our .m4 files.
if test -f $m4base/gettext.m4; then
echo "executing ${AUTOPOINT} --force"
- ${AUTOPOINT} --force
+ ${AUTOPOINT} --force || func_exit 1
for f in $m4base/*.m4~; do
- mv $f `echo $f | sed -e 's,~$,,'`
+ mv -f $f `echo $f | sed -e 's,~$,,'` || func_exit 1
done
fi
- echo "executing ${ACLOCAL} --force -I $m4base"
- ${ACLOCAL} --force -I $m4base
+ echo "executing ${ACLOCAL} -I $m4base"
+ ${ACLOCAL} -I $m4base || func_exit 1
if ! test -d build-aux; then
echo "executing mkdir build-aux"
- mkdir build-aux
+ mkdir build-aux || func_exit 1
fi
- echo "executing ${AUTOCONF} --force"
- ${AUTOCONF} --force
- echo "executing ${AUTOHEADER} --force"
- ${AUTOHEADER} --force
- echo "executing ${AUTOMAKE} --add-missing --copy --force-missing"
- ${AUTOMAKE} --add-missing --copy --force-missing
- )
+ echo "executing ${AUTOCONF}"
+ ${AUTOCONF} || func_exit 1
+ echo "executing ${AUTOHEADER}"
+ ${AUTOHEADER} || func_exit 1
+ echo "executing ${AUTOMAKE} --add-missing --copy"
+ ${AUTOMAKE} --add-missing --copy || func_exit 1
+ ) || func_exit 1
+ # Create autogenerated files.
+ (cd "$testdir/$testsbase" || func_exit 1
+ # Do not use "${AUTORECONF} --force --install", because it may invoke
+ # autopoint, which brings in older versions of some of our .m4 files.
+ if test -f ../$m4base/gettext.m4; then
+ echo "executing ${AUTOPOINT} --force"
+ ${AUTOPOINT} --force || func_exit 1
+ for f in ../$m4base/*.m4~; do
+ mv -f $f `echo $f | sed -e 's,~$,,'` || func_exit 1
+ done
+ fi
+ echo "executing ${ACLOCAL} -I ../$m4base"
+ ${ACLOCAL} -I ../$m4base || func_exit 1
+ if ! test -d ../build-aux; then
+ echo "executing mkdir ../build-aux"
+ mkdir ../build-aux
+ fi
+ echo "executing ${AUTOCONF}"
+ ${AUTOCONF} || func_exit 1
+ echo "executing ${AUTOHEADER}"
+ ${AUTOHEADER} || func_exit 1
+ echo "executing ${AUTOMAKE} --add-missing --copy"
+ ${AUTOMAKE} --add-missing --copy || func_exit 1
+ ) || func_exit 1
if grep '^BUILT_SOURCES *+=' "$testdir/$sourcebase/Makefile.am" > /dev/null;
then
(cd "$testdir"
- ./configure
+ ./configure || func_exit 1
cd "$sourcebase"
echo 'built_sources: $(BUILT_SOURCES)' >> Makefile
- make built_sources
+ make built_sources || func_exit 1
cd ..
Announce: vc-dwim-0.2.2, includes new, ChangeLog-writing tool: vc-chlog
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've just made a new release of vc-dwim:
Here are the files:
http://et.redhat.com/~meyering/vc-dwim-0.2.2.tar.gz
http://et.redhat.com/~meyering/vc-dwim-0.2.2.tar.gz.sig
You can check out the sources like this:
hg clone http://hg.et.redhat.com/hg/emd/applications/vc-dwim
There have been some bug fixes and portability improvements, but
the biggest change is the addition of a new script, vc-chlog,
by Ralf Wildenhues.
Here's the README file. The latter part tells about the new tool.
-
vc-dwim is a version-control-agnostic ChangeLog diff and commit tool.
vc-chlog is a ChangeLog writing helper tool.
It is useful if you like to maintain a ChangeLog file describing
the changes you make to version-controlled files. vc-dwim works with
the following version control systems: git, mercurial, svn, and cvs.
It should be easy to add support for more.
What can vc-dwim do?
vc-dwim can save you from making some small mistakes when using
version control programs from the command line.
For example, if you have unsaved changes in an editor buffer and use
vc-dwim to print diffs or to commit changes involving that file, it will
detect the problem, tell you about it, and fail. This works as long as
you use Emacs or Vim.
Another common error you can avoid with this tool is the one where you
create a new file, add its name to Makefiles, etc., mention the addition
in a ChangeLog, but forget to e.g., "git add" (or "hg add", etc.) the
file to the version control system. vc-dwim detects this discrepancy
and fails with a diagnostic explaining the probable situation. You might
also have simply mistyped the file name in the ChangeLog.
Also, vc-dwim makes it a little easier/safer to commit a strict subset
of the modified files in a working directory. But no one ever does *that*.
How can you use vc-dwim?
Print diffs of arbitrary files:
- --
Use an alias like this to show all or specified diffs:
cv='vc-dwim --diff'
Use that when you want to see diffs of a specified file, regardless
of whether you have written new ChangeLog entries for it.
It works the same for cvs, git, hg, svn repositories, as long as
all you want are the difference between your local copy and the
checked out version.
Print diffs of files with new ChangeLog entries:
- ---
Let's say you have made local changes to a file, and you've also added
at least one corresponding entry in a ChangeLog file. Then, you can use
"vc-dwim ChangeLog" to print the diffs for which there are ChangeLog
entries, warning about the potential problems mentioned above (editor
temporaries that can imply there are unsaved changes, and files listed in
ChangeLog, but not "cvs add"ed). If your changes affect files covered by
more than one ChangeLog, you might use "vc-dwim ChangeLog lib/ChangeLog",
or more concisely, "vc-dwim {,lib/}ChangeLog".
Commit changes to files with new ChangeLog entries:
- --
Use "vc-dwim --commit ChangeLog"
or "vc-dwim --commit ChangeLog lib/ChangeLog src/ChangeLog"
to commit the changes you would see without the --commit option.
Assuming you have completed a change and have documented everything in
one or more ChangeLog file, run "vc-dwim --commit ChangeLog" to commit
that ChangeLog file and the files "implied" by the new ChangeLog lines.
The commit log message is derived from the added ChangeLog lines. With a
single ChangeLog file, the log message is nearly identical to the list
of added lines. One leading TAB is removed and any "date user-name "
lines are elided. When there are two or more ChangeLog files, the log
message includes a line for each indicating the affected directory.
For example:
[ChangeLog]
* some-file-in-top-level-dir: ...
[lib/ChangeLog]
* lib.c: ...
[m4/ChangeLog]
* foo.m4: ...
What can vc-chlog do?
=
vc-chlog is about writing GNU Coding Standards-compliant ChangeLog
entries easily.
Say you have made some changes to your code, ready to be committed.
The only remaining part is to write one or more ChangeLog entries:
for each ChangeLog governing a part of the package, collect the list
of changed files, in each file list the changed functions, and mention
all of those, in order to afterwards describe the changes:
* file1.c (foo, bar, ...): ...
* file2.c (baz): ...
vc-chlog attempts to help with this step. It scans the diff (obtained
by "vc-dwim --diff" or passed on standard input with --stdin) for the
files that were touched and the set of lines that have been changed.
It then uses the "ctags" program to try to find out in which functions
those changes have occurred, and formats the file and functions names
in a prototype ChangeLog entry form on standard output.
There is a crucial assumption behind this idea to work well in practice:
ctags should be able to
Re: [bug-gnulib] Re: gnulib-tool --with-tests --test
Ralf Wildenhues wrote: > The patch below should some of the reported issues. OK to apply? Thanks for this patch. Everything except the first hunk (gl_source_base) is fine. Please apply. About the gl_source_base of the tests directory: The idea is that the tests directory has its sources separate from the main directory, so that when a dependency (providing a .h file, for example) is missing from a library module but present in the tests module, we still an error while compiling the library. Otherwise testing with --with-tests might fail to uncover dependency bugs that --without-tests would uncover; this is obviously undesirable. - Can you find another fix for the problem? > FWIW, I still don't understand the necessity of a separate configure > script in the gltests/ subdirectory at all. Is that just for testing > purposes? Like above: If the tests module requires an m4 macro invocation that the library module would also need but lacks, --with-tests would not uncover the bug. Bruno
FYI: tiny change in fts.c
I've just checked in this change:
* lib/fts.c [FTS_DEBUG]: Don't try to print a pointer via %s.
Index: lib/fts.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/fts.c,v
retrieving revision 1.25
diff -u -r1.25 fts.c
--- lib/fts.c 8 Nov 2006 13:49:24 - 1.25
+++ lib/fts.c 10 Nov 2006 22:21:31 -
@@ -707,7 +707,7 @@
sp->fts_cur = p;
if (p->fts_info == FTS_D)
{
- Dprintf ((" %s-entering: %s\n", sp, p->fts_path));
+ Dprintf ((" entering: %s\n", p->fts_path));
if (! enter_dir (sp, p))
{
__set_errno (ENOMEM);
Re: coreutils-6.4 released (stable)
Matthew Woehlke <[EMAIL PROTECTED]> writes: > I'm quite certain I remember it bombing (there are 'unsigned long > long's sprinkled in there without it). But I am guessing the problem > is just that CVS is a little off of coreutils-6.4, which is what I was > trying to patch. I think the main problems were things like > 'HAVE_LONG_LONG' vs. 'HAVE_LONG_LONG_INT' which caused 'patch' to > reject most of the hunks. Applying the patches by hand was fine and > (as I stated on bugs-m4) gave a successful build that passed 'make > check'. This is all very confusing, I'm afraid. I am not sure what works and what does not. Let's put it this way. I'd like a story that sounds like this: CVS coreutils + CVS gnulib does not work on my platform. When I do "configure; make", the "make" fails with the following symptoms. This is because "configure" sets up include files in such-and-such a way, and the standard include files work in such-and-such a way, and the C compiler has such-and-such properties. However, if I apply the enclosed patch before running "configure", then things work fine. Perhaps if you get some free time you can write down the exact story along those lines.
