Re: test-string-c++ test failure

[Jim Meyering]

Jim Meyering wrote:

> Bruno Haible wrote:
> ...
>> This should fix it:
>>
>> 2010-03-11  Bruno Haible  
>>
>>  Fix problems with overloaded C++ definitions of memchr, strpbrk, etc.
>>  * build-aux/c++defs.h (_GL_CXXALIAS_SYS_CAST2): Make it work regardless
>>  whether the system provides one variant or multiple variants of the
>>  function.
>>  * lib/string.in.h (memchr, strpbrk): Use _GL_CXXALIAS_SYS_CAST2 for all
>>  C++ compilers.
>>  (memrchr, rawmemchr, strchrnul, strstr, strcasestr): Use
>>  _GL_CXXALIAS_SYS_CAST2 instead of _GL_CXXALIAS_SYS.
>>  Reported by Jim Meyering.
>
> Thanks!
> That does indeed solve the problem for me.

FYI, I updated coreutils to use the version of gnulib
I'd confirmed to work on F12, and pushed the result.
However, it appears not to be the complete solution,
since the nixos hydra autobuilder reports a coreutils
build failure on linux-686:

  http://hydra.nixos.org/build/324839



Oh.  Rats.
I see my mistake.
I figured the failure (after update) was due to a stale lib/string.h,
so removed that and reran "make", which succeeded.
However, I should have rerun "make check".  *that* still fails,
even on F12.

In file included from test-string-c++.cc:23:
../lib/string.h:299: error: type of 'memchr' is unknown
../lib/string.h:299: error: invalid type in declaration before ';' token
../lib/string.h:299: error: 'int memchr' redeclared as different kind of symbol
/usr/include/string.h:76: error: previous declaration of 'const void* 
memchr(const void*, int, size_t)'
In file included from test-string-c++.cc:23:
../lib/string.h:375: error: type of 'memrchr' is unknown
../lib/string.h:375: error: invalid type in declaration before ';' token
../lib/string.h:375: error: 'int memrchr' redeclared as different kind of symbol
/usr/include/string.h:116: error: previous declaration of 'const void* 
memrchr(const void*, int, size_t)'
In file included from test-string-c++.cc:23:
../lib/string.h:580: error: type of 'strpbrk' is unknown
../lib/string.h:580: error: invalid type in declaration before ';' token
../lib/string.h:580: error: 'int strpbrk' redeclared as different kind of symbol
/usr/include/string.h:294: error: previous declaration of 'const char* 
strpbrk(const char*, const char*)'
In file included from test-string-c++.cc:23:
../lib/string.h:675: error: type of 'strstr' is unknown
../lib/string.h:675: error: invalid type in declaration before ';' token
../lib/string.h:675: error: 'int strstr' redeclared as different kind of symbol
/usr/include/string.h:321: error: previous declaration of 'const char* 
strstr(const char*, const char*)'

Re: C++ libtool build error?

[Ralf Wildenhues]

Hello,

* Bruno Haible wrote on Fri, Mar 12, 2010 at 01:15:14PM CET:
> 2010-03-12  Bruno Haible  
> 
>   Fix problem with automake's definition of CXXLINK.
>   * gnulib-tool (func_create_testdir): After LT_INIT, also use LT_LANG.
>   Reported by Simon Josefsson and Ludovic Courtès.

Is anyone aware of a way to reproduce the bug fixed by this patch
with gnulib-tool alone?  I'll look at libunistring next.

Thanks,
Ralf

Re: test-string-c++ test failure

[Bruno Haible]

Jim Meyering wrote:
> In file included from test-string-c++.cc:23:
> ../lib/string.h:299: error: type of 'memchr' is unknown
> ../lib/string.h:299: error: invalid type in declaration before ';' token
> ../lib/string.h:299: error: 'int memchr' redeclared as different kind of 
> symbol
> /usr/include/string.h:76: error: previous declaration of 'const void* 
> memchr(const void*, int, size_t)'
> In file included from test-string-c++.cc:23:
> ../lib/string.h:375: error: type of 'memrchr' is unknown
> ../lib/string.h:375: error: invalid type in declaration before ';' token
> ../lib/string.h:375: error: 'int memrchr' redeclared as different kind of 
> symbol
> /usr/include/string.h:116: error: previous declaration of 'const void* 
> memrchr(const void*, int, size_t)'
> In file included from test-string-c++.cc:23:
> ../lib/string.h:580: error: type of 'strpbrk' is unknown
> ../lib/string.h:580: error: invalid type in declaration before ';' token
> ../lib/string.h:580: error: 'int strpbrk' redeclared as different kind of 
> symbol
> /usr/include/string.h:294: error: previous declaration of 'const char* 
> strpbrk(const char*, const char*)'
> In file included from test-string-c++.cc:23:
> ../lib/string.h:675: error: type of 'strstr' is unknown
> ../lib/string.h:675: error: invalid type in declaration before ';' token
> ../lib/string.h:675: error: 'int strstr' redeclared as different kind of 
> symbol
> /usr/include/string.h:321: error: previous declaration of 'const char* 
> strstr(const char*, const char*)'

Ok, at least the _GL_CXXALIAS_SYS_CAST2 stuff is working fine now. The rest
is probably fixed this way:


2010-03-13  Bruno Haible  

Fix compilation error with glibc >= 2.10 and g++ >= 4.4.
* build-aux/warn-on-use.h (_GL_WARN_ON_USE_CXX): New macro.
* build-aux/c++defs.h (_GL_CXXALIASWARN1): New macro.
* lib/string.in.h (memchr, memrchr, rawmemchr, strchrnul, strpbrk,
strstr, strcasestr): Use _GL_CXXALIASWARN1 instead of _GL_CXXALIASWARN
when appropriate.
Reported by Jim Meyering.

--- build-aux/c++defs.h.origSat Mar 13 12:02:10 2010
+++ build-aux/c++defs.h Sat Mar 13 11:39:30 2010
@@ -196,13 +196,14 @@
 
 /* _GL_CXXALIASWARN (func);
causes a warning to be emitted when ::func is used but not when
-   GNULIB_NAMESPACE::func is used.  */
+   GNULIB_NAMESPACE::func is used.  func must be defined without overloaded
+   variants.  */
 #if defined __cplusplus && defined GNULIB_NAMESPACE
 # define _GL_CXXALIASWARN(func) \
-   _GL_CXXALIASWARN1 (func, GNULIB_NAMESPACE)
-# define _GL_CXXALIASWARN1(func,namespace) \
-   _GL_CXXALIASWARN2 (func, namespace)
-# define _GL_CXXALIASWARN2(func,namespace) \
+   _GL_CXXALIASWARN_1 (func, GNULIB_NAMESPACE)
+# define _GL_CXXALIASWARN_1(func,namespace) \
+   _GL_CXXALIASWARN_2 (func, namespace)
+# define _GL_CXXALIASWARN_2(func,namespace) \
_GL_WARN_ON_USE (func, \
 "The symbol ::" #func " refers to the system function. " \
 "Use " #namespace "::" #func " instead.")
@@ -211,4 +212,22 @@
 _GL_EXTERN_C int _gl_cxxalias_dummy
 #endif
 
+/* _GL_CXXALIASWARN1 (func, rettype, parameters_and_attributes);
+   causes a warning to be emitted when the given overloaded variant of ::func
+   is used but not when GNULIB_NAMESPACE::func is used.  */
+#if defined __cplusplus && defined GNULIB_NAMESPACE
+# define _GL_CXXALIASWARN1(func,rettype,parameters_and_attributes) \
+#  _GL_CXXALIASWARN1_1 (func, rettype, parameters_and_attributes, \
+GNULIB_NAMESPACE)
+# define _GL_CXXALIASWARN1_1(func,rettype,parameters_and_attributes,namespace) 
\
+   _GL_CXXALIASWARN1_2 (func, rettype, parameters_and_attributes, namespace)
+# define _GL_CXXALIASWARN1_2(func,rettype,parameters_and_attributes,namespace) 
\
+   _GL_WARN_ON_USE_CXX (func, rettype, parameters_and_attributes, \
+"The symbol ::" #func " refers to the system function. 
" \
+"Use " #namespace "::" #func " instead.")
+#else
+# define _GL_CXXALIASWARN1(func,rettype,parameters_and_attributes) \
+_GL_EXTERN_C int _gl_cxxalias_dummy
+#endif
+
 #endif /* _GL_CXXDEFS_H */
--- build-aux/warn-on-use.h.origSat Mar 13 12:02:10 2010
+++ build-aux/warn-on-use.h Sat Mar 13 11:30:03 2010
@@ -14,7 +14,7 @@
You should have received a copy of the GNU Lesser General Public License
along with this program.  If not, see .  */
 
-/* _GL_WARN_ON_USE(function, "literal string") issues a declaration
+/* _GL_WARN_ON_USE (function, "literal string") issues a declaration
for FUNCTION which will then trigger a compiler warning containing
the text of "literal string" anywhere that function is called, if
supported by the compiler.  If the compiler does not support this
@@ -73,3 +73,20 @@
 extern int _gl_warn_on_use
 # endif
 #endif
+
+/* _GL_WARN_ON_USE_CXX (function, rettype, parameters_and_attributes, "string")
+   is like _GL_W

Re: C++ libtool build error?

[Bruno Haible]

Ralf Wildenhues asks:
> > Fix problem with automake's definition of CXXLINK.
> > * gnulib-tool (func_create_testdir): After LT_INIT, also use LT_LANG.
> > Reported by Simon Josefsson and Ludovic Courtès.
> 
> Is anyone aware of a way to reproduce the bug fixed by this patch
> with gnulib-tool alone?

Here's how to:
  - Check out the newest gnulib.
  $ ./gnulib-tool --create-testdir --dir=/tmp/testdir --libtool --with-tests 
string
  $ cd /tmp/testdir
  - In configure.ac and gltests/configure.ac, change LT_LANG([C++]) to
LT_LANG([Windows Resource]).
  $ autoreconf -v
  $ ./configure
  $ make

Results:
/bin/sh ./libtool   --mode=link g++ -o test-string-c++ test-string-c++.o 
../gllib/libgnu.la  
libtool: link: unable to infer tagged configuration
libtool: link: specify a tag with `--tag'
make[4]: *** [test-string-c++] Error 1

Bruno

Re: test-string-c++ test failure

[Jim Meyering]

Bruno Haible wrote:
> Jim Meyering wrote:
>> In file included from test-string-c++.cc:23:
>> ../lib/string.h:299: error: type of 'memchr' is unknown
>> ../lib/string.h:299: error: invalid type in declaration before ';' token
>> ../lib/string.h:299: error: 'int memchr' redeclared as different kind of 
>> symbol
>> /usr/include/string.h:76: error: previous declaration of 'const void* 
>> memchr(const void*, int, size_t)'
>> In file included from test-string-c++.cc:23:
>> ../lib/string.h:375: error: type of 'memrchr' is unknown
>> ../lib/string.h:375: error: invalid type in declaration before ';' token
>> ../lib/string.h:375: error: 'int memrchr' redeclared as different kind of 
>> symbol
>> /usr/include/string.h:116: error: previous declaration of 'const void* 
>> memrchr(const void*, int, size_t)'
>> In file included from test-string-c++.cc:23:
>> ../lib/string.h:580: error: type of 'strpbrk' is unknown
>> ../lib/string.h:580: error: invalid type in declaration before ';' token
>> ../lib/string.h:580: error: 'int strpbrk' redeclared as different kind of 
>> symbol
>> /usr/include/string.h:294: error: previous declaration of 'const char* 
>> strpbrk(const char*, const char*)'
>> In file included from test-string-c++.cc:23:
>> ../lib/string.h:675: error: type of 'strstr' is unknown
>> ../lib/string.h:675: error: invalid type in declaration before ';' token
>> ../lib/string.h:675: error: 'int strstr' redeclared as different kind of 
>> symbol
>> /usr/include/string.h:321: error: previous declaration of 'const char* 
>> strstr(const char*, const char*)'
>
> Ok, at least the _GL_CXXALIAS_SYS_CAST2 stuff is working fine now. The rest
> is probably fixed this way:
>
>
> 2010-03-13  Bruno Haible  
>
>   Fix compilation error with glibc >= 2.10 and g++ >= 4.4.
>   * build-aux/warn-on-use.h (_GL_WARN_ON_USE_CXX): New macro.
>   * build-aux/c++defs.h (_GL_CXXALIASWARN1): New macro.
>   * lib/string.in.h (memchr, memrchr, rawmemchr, strchrnul, strpbrk,
>   strstr, strcasestr): Use _GL_CXXALIASWARN1 instead of _GL_CXXALIASWARN
>   when appropriate.
>   Reported by Jim Meyering.

Speedy!  Thank you.
This time I really have confirmed that it's fixed.
coreutils' "make distcheck" passed.

Re: gnulib-tool: allow --libtool with --create-testdir

[Bruno Haible]

> 2010-03-08  Bruno Haible  
> 
>   gnulib-tool: Add support for --libtool in --create-testdir.

This documents it the new option:


2010-03-13  Bruno Haible  

* gnulib-tool (func_usage): Clarify which options are available for
--create-testdir and --create-megatestdir.

--- gnulib-tool.origSat Mar 13 16:10:27 2010
+++ gnulib-tool Sat Mar 13 16:07:39 2010
@@ -189,6 +189,20 @@
   --verbose Increase verbosity. May be repeated.
   --quiet   Decrease verbosity. May be repeated.
 
+Options for --import, --update:
+  --dry-run Only print what would have been done.
+
+Options for --import, --create-[mega]testdir, --[mega]test:
+  --with-tests  Include unit tests for the included modules.
+  --with-obsolete   Include obsolete modules when they occur among the
+dependencies. By default, dependencies to obsolete
+modules are ignored.
+  --avoid=MODULEAvoid including the given MODULE. Useful if you
+have code that provides equivalent functionality.
+This option can be repeated.
+  --libtool Use libtool rules.
+  --no-libtool  Don't use libtool rules.
+
 Options for --import:
   --lib=LIBRARY Specify the library name.  Defaults to 'libgnu'.
   --source-base=DIRECTORY
@@ -205,13 +219,6 @@
 placed (default \"tests\").
   --aux-dir=DIRECTORY   Directory relative to --dir where auxiliary build
 tools are placed (default \"build-aux\").
-  --with-tests  Include unit tests for the included modules.
-  --with-obsolete   Include obsolete modules when they occur among the
-dependencies. By default, dependencies to obsolete
-modules are ignored.
-  --avoid=MODULEAvoid including the given MODULE. Useful if you
-have code that provides equivalent functionality.
-This option can be repeated.
   --lgpl[=2|=3] Abort if modules aren't available under the LGPL.
 Also modify license template from GPL to LGPL.
 The version number of the LGPL can be specified;
@@ -219,8 +226,6 @@
   --makefile-name=NAME  Name of makefile in automake syntax in the
 source-base and tests-base directories
 (default \"Makefile.am\").
-  --libtool Use libtool rules.
-  --no-libtool  Don't use libtool rules.
   --macro-prefix=PREFIX  Specify the prefix of the macros 'gl_EARLY' and
 'gl_INIT'. Default is 'gl'.
   --po-domain=NAME  Specify the prefix of the i18n domain. Usually use
@@ -230,11 +235,12 @@
 (.gitignore and/or .cvsignore).
   --no-changelogDon't update or create ChangeLog files.
 
-Options for --import and --update:
-  --dry-run For --import, only print what would have been done.
+Options for --import, --update, --create-[mega]testdir, --[mega]test:
   -s, --symbolic, --symlink Make symbolic links instead of copying files.
   --local-symlink   Make symbolic links instead of copying files, only
 for files from the local override directory.
+
+Options for --import, --update:
   -S, --more-symlinks   Make symbolic links instead of copying files, and
 don't replace copyright notices.
 
@@ -4413,6 +4419,15 @@
 # - local_gnulib_dir  from --local-dir
 # - modcachetrue or false, from --cache-modules/--no-cache-modules
 # - auxdir  directory relative to destdir where to place build aux 
files
+# - incteststrue if tests should be included, blank otherwise
+# - incobsolete true if obsolete modules among dependencies should be
+#   included, blank otherwise
+# - avoidlist   list of modules to avoid
+# - libtool true if --libtool was given, false if --no-libtool was
+#   given, blank otherwise
+# - symbolictrue if files should be symlinked, copied otherwise
+# - lsymbolic   true if files from local_gnulib_dir should be symlinked,
+#   copied otherwise
 func_create_testdir ()
 {
   testdir="$1"

Re: status of new 'c++defs' module?

[Bruno Haible]

Hi John,

> OK, I tried updating and using the new c++defs module and hit an
> error with memchr and memrchr.
> ...
>   In file included from /usr/include/c++/4.4/cstring:46,
>from /home/jwe/src/octave/liboctave/foo.cc:3:
>   ../libgnu/string.h:298: error: no matches converting function 'memchr' to 
> type 'void* (*)(const void*, int, size_t)'
>   /usr/include/string.h:74: error: candidates are: void* memchr(void*, int, 
> size_t)
>   /usr/include/string.h:76: error: const void* memchr(const 
> void*, int, size_t)
>   ../libgnu/string.h:301: error: type of 'memchr' is unknown
>   ../libgnu/string.h:301: error: invalid type in declaration before ';' token
>   ../libgnu/string.h:301: error: 'int memchr' redeclared as different kind of 
> symbol
>   /usr/include/string.h:76: error: previous declaration of 'const void* 
> memchr(const void*, int, size_t)'
>   In file included from /usr/include/c++/4.4/cstring:46,
>from /home/jwe/src/octave/liboctave/foo.cc:3:
>   ../libgnu/string.h:371: error: no matches converting function 'memrchr' to 
> type 'void* (*)(const void*, int, size_t)'
>   /usr/include/string.h:114: error: candidates are: void* memrchr(void*, int, 
> size_t)
>   /usr/include/string.h:116: error: const void* memrchr(const 
> void*, int, size_t)
>   ../libgnu/string.h:372: error: type of 'memrchr' is unknown
>   In file included from /usr/include/c++/4.4/cstring:46,
>from /home/jwe/src/octave/liboctave/foo.cc:3:
>   ../libgnu/string.h:372: error: invalid type in declaration before ';' token
>   ../libgnu/string.h:372: error: 'int memrchr' redeclared as different kind 
> of symbol
>   /usr/include/string.h:116: error: previous declaration of 'const void* 
> memrchr(const void*, int, size_t)'

I guess that this was the same error that Jim was observing; so I guess it is
fixed now.

> I tried compiling a simple example that just includes two files:
> 
>   #include 
>   #include 

Good point. I'm adding this as an extra check in the testsuite:


2010-03-13  Bruno Haible  

Test that gnulib does not break the standard C++ headers.
* tests/test-locale-c++2.cc: New file.
* modules/locale-tests (Files): Add it.
(Makefile.am): Compile it for test-locale-c++.
* tests/test-math-c++2.cc: New file.
* modules/math-tests (Files): Add it.
(Makefile.am): Compile it for test-math-c++.
* tests/test-signal-c++2.cc: New file.
* modules/signal-tests (Files): Add it.
(Makefile.am): Compile it for test-signal-c++.
* tests/test-stdio-c++2.cc: New file.
* modules/stdio-tests (Files): Add it.
(Makefile.am): Compile it for test-stdio-c++.
* tests/test-stdlib-c++2.cc: New file.
* modules/stdlib-tests (Files): Add it.
(Makefile.am): Compile it for test-stdlib-c++.
* tests/test-string-c++2.cc: New file.
* modules/string-tests (Files): Add it.
(Makefile.am): Compile it for test-string-c++.
* tests/test-time-c++2.cc: New file.
* modules/time-tests (Files): Add it.
(Makefile.am): Compile it for test-time-c++.
Reported by John W. Eaton .

== tests/test-string-c++2.cc ==
/* Test of  substitute in C++ mode.
   Copyright (C) 2010 Free Software Foundation, Inc.

   This program is free software: you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 3 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program.  If not, see .  */

#define GNULIB_NAMESPACE gnulib
#include 

#include 

Re: C++ libtool build error?

[Bruno Haible]

Simon Josefsson wrote:
> ... we need to bump the required libtool version to 2.2.x

Good point, I had forgotten to do this:


2010-03-13  Bruno Haible  

* DEPENDENCIES (libtool): Mention libtool 2.2.x requirement in special
cases.

*** DEPENDENCIES.orig   Sat Mar 13 16:31:08 2010
--- DEPENDENCIESSat Mar 13 16:29:01 2010
***
*** 138,143 
--- 138,145 
  * GNU libtool 1.5.22 or newer.
+ Optional.
  Needed if you want to invoke gnulib-tool with option --libtool.
+ libtool 2.2.x or newer is needed if you want to invoke gnulib-tool
+ with options --create-testdir/--test  and --libtool.
+ Homepage:
  http://www.gnu.org/software/libtool/
+ Download:

Re: C++ libtool build error?

[Bruno Haible]

Eric Blake wrote:
> Which begs the question - why is gnulib-tool making C-only projects to
> import C++ test files?  It seems like C++ files should be excluded
> unless the developer explicitly requests that both C and C++ be supported.

Simon Josefsson wrote:
> > So, the fix is to add an LT_LANG([CXX]) invocation to your configure.ac.
> > This fixes it for libunistring.
> 
> That doesn't make a lot of sense to me because
> 
>1) It violates the modularity of gnulib.  Gnulib is adding the C++
>   code to my project, so I believe gnulib should be responsible for
>   making sure the files build.
> 
>2) LT_LANG([CXX]) doesn't exist in libtool 1.5.x which is still
>   supported by gnulib.
> 
> The fix you applied is just for --create-testdir (right?) so that patch
> by itself doesn't modify anything for libidn or libunistring as far as I
> can tell.
> ...
> Alternatively, some solution that detected that C++ code isn't relevant
> for the particular project, and didn't try to build those files.

Actually, there are quite a number of tests that not every project may
want to carry in its testsuite, but that should be packageable via
--create-testdir:
  - The C++ tests of the modules 'string', 'stdlib', etc.
  - The tests that ask for the superuser password ('idpriv-drop',
'idpriv-droptemp').
  - The long-running tests of the 'havelib' module (currently still in
gettext).

The solution I would propose is to put them into a module '*-extratests'.
It is like '*-tests', except that it is not included by default in
--with-tests.


Additionally, the user who installs a package might want to disable the C++
part even if it is packaged as part of the tarball. I'm applying this.

2010-03-13  Bruno Haible  

Allow the user to disable C++ code and tests.
* m4/ansi-c++.m4 (gl_CXX_CHOICE): New macro.
(gl_PROG_ANSI_CXX): Require it.

--- m4/ansi-c++.m4.orig Sat Mar 13 17:30:01 2010
+++ m4/ansi-c++.m4  Sat Mar 13 17:28:22 2010
@@ -1,11 +1,26 @@
-# ansi-c++.m4 serial 2
-dnl Copyright (C) 2002-2003, 2010 Free Software Foundation, Inc.
+# ansi-c++.m4 serial 3
+dnl Copyright (C) 2002-2003, 2005, 2010 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
 dnl with or without modifications, as long as this notice is preserved.
 
 dnl From Bruno Haible.
 
+# Sets CXX_CHOICE to 'yes' or 'no', depending on the preferred use of C++.
+
+AC_DEFUN([gl_CXX_CHOICE],
+[
+  AC_MSG_CHECKING([whether to use C++])
+  dnl It would be so nice if plus signs were supported in AC_ARG_ENABLE.
+  dnl Feature request submitted on 2010-03-13.
+  AC_ARG_ENABLE([cxx],
+[  --disable-cxx   do not build C++ sources],
+[CXX_CHOICE="$enableval"],
+[CXX_CHOICE=yes])
+  AC_MSG_RESULT([$CXX_CHOICE])
+  AC_SUBST([CXX_CHOICE])
+])
+
 # gl_PROG_ANSI_CXX([ANSICXX_VARIABLE], [ANSICXX_CONDITIONAL])
 # Sets ANSICXX_VARIABLE to the name of a sufficiently ANSI C++ compliant
 # compiler, or to ":" if none is found.
@@ -14,8 +29,12 @@
 
 AC_DEFUN([gl_PROG_ANSI_CXX],
 [
+  AC_REQUIRE([gl_CXX_CHOICE])
   m4_if([$1], [CXX], [],
 [gl_save_CXX="$CXX"])
+  if test "$CXX_CHOICE" = no; then
+CXX=":"
+  fi
   if test -z "$CXX"; then
 if test -n "$CCC"; then
   CXX="$CCC"

Re: C++ libtool build error?

[Jim Meyering]

Bruno Haible wrote:
> Eric Blake wrote:
...
>> Alternatively, some solution that detected that C++ code isn't relevant
>> for the particular project, and didn't try to build those files.
>
> Actually, there are quite a number of tests that not every project may
> want to carry in its testsuite, but that should be packageable via
> --create-testdir:
>   - The C++ tests of the modules 'string', 'stdlib', etc.
>   - The tests that ask for the superuser password ('idpriv-drop',
> 'idpriv-droptemp').
>   - The long-running tests of the 'havelib' module (currently still in
> gettext).
>
> The solution I would propose is to put them into a module '*-extratests'.
> It is like '*-tests', except that it is not included by default in
> --with-tests.

Hi Bruno,

I like the idea of being able to exclude tests
based on categories like those.

Rather than lumping them all into one "-extratests" category
that is tied to the module file name, have you considered
adding new module attributes?

Then, we could give any module one or more attributes,
and eventually exclude based on those attributes.
For example, if a package maintainer wants to avoid C++ tests,
they could do that without unnecessarily excluding long-running
ones as well.  And when this year's long-running test no longer
deserves its title in 2013, we won't have to change its name
to put it back in the set of tests everyone runs by default.

Re: C++ libtool build error?

[Bruno Haible]

Hi Jim,

> Rather than lumping them all into one "-extratests" category
> that is tied to the module file name, have you considered
> adding new module attributes?
> 
> Then, we could give any module one or more attributes,
> and eventually exclude based on those attributes.
> For example, if a package maintainer wants to avoid C++ tests,
> they could do that without unnecessarily excluding long-running
> ones as well.

So, gnulib-tool would have command-line options
  --with[out]-long-running-tests
  --with[out]-unportable-tests [for tests that fail on some platforms,
e.g. flock, unlink, poll]
  --with[out]-c++-tests
?

Sounds very reasonable to me.

IMO the default for --import and --update should be that these
tests are all turned off by default. For --create-testdir the
default has to be the same, otherwise people will be too confused.
Therefore a new option --with-all-tests will be required, for
the normal use of --create-testdir.

> And when this year's long-running test no longer 
> deserves its title in 2013, we won't have to change its name
> to put it back in the set of tests everyone runs by default.

Yes, simply removing the attribute "long-running" will do it.

I like your idea.

Bruno