Re: CI with clang 18 ?

[Bruno Haible]

I wrote:
> so I can know why the CI did not report it within three weeks

That was because the compilation error occurred only with clang 18,
which was released in March 2024 and is therefore not yet present
in the *BSD distros.

In the last two years, I got the feeling that clang is adopting new
ISO C features more quickly than GCC (seen with the K&R prototypes
removal in clang 16, now with ckd_add in clang 18). So, would it
make sense to do a CI build with the newest released clang version?

In contrast, a CI build with the newest released gcc version seems
less urgent, since
  - Fedora jumps on the newest gcc quickly,
  - gcc is not so frequently ahead of clang regarding ISO C language
features.
Right?

Opinions?

  Bruno

Re: CI with clang 18 ?

[Paul Eggert]

On 7/13/24 09:15, Bruno Haible wrote:

In the last two years, I got the feeling that clang is adopting new
ISO C features more quickly than GCC (seen with the K&R prototypes
removal in clang 16, now with ckd_add in clang 18).


I don't have that feeling. I would put it differently, since GCC has 
supported the ckd_add stuff for some time, and has merely been reluctant 
to refuse to support K&R style function definitions (which C23 still 
allows as an extension).


I would instead say that GCC is more willing to support C23 extensions 
than Clang is.

tests: Don't depend on the exact locale name

[Bruno Haible]

The locale names that I hardcoded in some tests are not those present in
some systems. This patch fixes it.


2024-07-13  Bruno Haible  

tests: Don't depend on the exact locale name.
* tests/test-c-ctype.c: Include .
(main): Test the return value of setlocale(). Try not only de_DE, but
also de_DE.ISO-8859-1.
* tests/test-vasnprintf-posix3.c (main): Try not only fa_IR.UTF-8, but
also fa_IR.
* tests/test-vasnwprintf-posix3.c (main): Likewise.

diff --git a/tests/test-c-ctype.c b/tests/test-c-ctype.c
index 898e79cc8a..7816543a72 100644
--- a/tests/test-c-ctype.c
+++ b/tests/test-c-ctype.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "macros.h"
 
@@ -218,11 +219,16 @@ main ()
 
   test_all ();
 
-  setlocale (LC_ALL, "de_DE");
-  test_all ();
+  /* Run the tests in a German unibyte locale.  */
+  if ((setlocale (LC_ALL, "de_DE") != NULL
+   || setlocale (LC_ALL, "de_DE.ISO-8859-1") != NULL)
+  && MB_CUR_MAX == 1)
+test_all ();
 
-  setlocale (LC_ALL, "ja_JP.EUC-JP");
-  test_all ();
+  /* Run the tests in a traditional Japanese locale.  */
+  if (setlocale (LC_ALL, "ja_JP.EUC-JP") != NULL
+  && MB_CUR_MAX == 2)
+test_all ();
 
   return test_exit_status;
 }
diff --git a/tests/test-vasnprintf-posix3.c b/tests/test-vasnprintf-posix3.c
index 0db514c601..568bfa912e 100644
--- a/tests/test-vasnprintf-posix3.c
+++ b/tests/test-vasnprintf-posix3.c
@@ -79,7 +79,8 @@ main (int argc, char *argv[])
 {
 #if (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 3)) && !defined 
__UCLIBC__
   /* Select a locale with Arabic 'outdigits'.  */
-  if (setlocale (LC_ALL, "fa_IR.UTF-8") == NULL)
+  if (setlocale (LC_ALL, "fa_IR.UTF-8") == NULL
+  && setlocale (LC_ALL, "fa_IR") == NULL)
 {
   fprintf (stderr, "Skipping test: no Iranian locale is installed\n");
   return 77;
diff --git a/tests/test-vasnwprintf-posix3.c b/tests/test-vasnwprintf-posix3.c
index f2ddc82660..53923bab77 100644
--- a/tests/test-vasnwprintf-posix3.c
+++ b/tests/test-vasnwprintf-posix3.c
@@ -83,7 +83,8 @@ main (int argc, char *argv[])
 {
 #if (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 3)) && !defined 
__UCLIBC__
   /* Select a locale with Arabic 'outdigits'.  */
-  if (setlocale (LC_ALL, "fa_IR.UTF-8") == NULL)
+  if (setlocale (LC_ALL, "fa_IR.UTF-8") == NULL
+  && setlocale (LC_ALL, "fa_IR") == NULL)
 {
   fprintf (stderr, "Skipping test: no Iranian locale is installed\n");
   return 77;

doc: Revamp list of dependencies

[Bruno Haible]

This patch improves the DEPENDENCIES file, mainly by distinguishing the
maintainer environment and the target environment.


2024-07-13  Bruno Haible  

doc: Revamp list of dependencies.
* DEPENDENCIES: Clarify that GNU make is only needed on OpenBSD and
Solaris. Mark GNU tar as optional, not recommended. Add note about
Solaris 10. Add a second section "Dependencies for building the imported
code". Document the needed locales.

diff --git a/DEPENDENCIES b/DEPENDENCIES
index 893daef0a7..2c38edc5ad 100644
--- a/DEPENDENCIES
+++ b/DEPENDENCIES
@@ -1,10 +1,21 @@
-The following packages are needed by maintainers for using
-'gnulib-tool'.  In general, Gnulib prefers the latest stable
-version of each package, but in some cases it also supports
-older versions; this caters to commonly-used software
-distributions that may lag behind the latest stable package.
-Support for older versions is not guaranteed, though, and
-the version numbers in the following list may be incremented
+Table of contents:
+1) Dependencies for using gnulib-tool (maintainer environment)
+2) Dependencies for building the imported code (target environment)
+
+
+1) Dependencies for using gnulib-tool (maintainer environment)
+**
+
+The following packages are needed by maintainers for using 'gnulib-tool'.
+We call this the "maintainer environment", although it is not necessarily
+a maintainer's or developer's machine; it can also be some containerized
+environment.
+
+In general, Gnulib prefers the latest stable version of each package,
+but in some cases it also supports older versions; this caters to
+commonly-used software distributions that may lag behind the latest
+stable package. Support for older versions is not guaranteed, though,
+and the version numbers in the following list may be incremented
 at any time.
 
 * A C runtime, compiler, linker, etc.
@@ -17,8 +28,8 @@ at any time.
 
 * A 'make' utility.
   + Mandatory. Using the platform's native 'make' gives good portability
-exposure for in-tree builds, but VPATH builds require GNU Make 3.79.1 or
-newer.
+exposure for in-tree builds, but VPATH builds on OpenBSD or Solaris
+require GNU Make 3.79.1 or newer.
   + GNU Make Homepage:
 https://www.gnu.org/software/make/
   + Download:
@@ -190,7 +201,7 @@ at any time.
 https://ftp.gnu.org/gnu/libtool/
 
 * GNU tar 1.28 or newer.
-  + Recommended.
+  + Optional.
 Needed if you use the 'gnumakefile' module, which sets TAR_OPTIONS
 to --sort=names (added in version 1.28) in GNUmakefile for 'make dist'.
   + Homepage:
@@ -198,9 +209,77 @@ at any time.
   + Download:
 https://ftp.gnu.org/gnu/tar/
 
+Note: Solaris 10 is no longer supported as maintainer environment.
+
+
+
+2) Dependencies for building the imported code (target environment)
+***
 
-Prerequisites needed on specific platforms
-==
+The following packages are needed for building the package that imports
+code from Gnulib.
+
+* A C runtime, compiler, linker, etc.
+  + Mandatory. Using the platform's native 'cc' gives good portability
+exposure, but you can also use GCC 3.1 or newer.
+  + GCC Homepage:
+https://gcc.gnu.org/
+  + Download:
+https://ftp.gnu.org/gnu/gcc/
+
+* A 'make' utility.
+  + Mandatory. Using the platform's native 'make' gives good portability
+exposure for in-tree builds, but VPATH builds on OpenBSD or Solaris
+require GNU Make 3.79.1 or newer.
+  + GNU Make Homepage:
+https://www.gnu.org/software/make/
+  + Download:
+https://ftp.gnu.org/gnu/make/
+
+* A shell
+  + Mandatory. Using the platform's native 'sh' gives good portability
+exposure, but you can also use Bash.
+  + Homepage:
+https://www.gnu.org/software/bash/
+  + Download:
+https://ftp.gnu.org/gnu/bash/
+
+* Core POSIX utilities, including:
+[ basename cat chgrp chmod chown cp dd echo expand expr
+false hostname install kill ln ls md5sum mkdir mkfifo
+mknod mv printenv pwd rm rmdir sleep sort tee test touch
+true uname
+  + Mandatory. Using the platform's native utilities gives good portability
+exposure, but you can also use GNU coreutils.
+  + Homepage:
+https://www.gnu.org/software/coreutils/
+  + Download:
+https://ftp.gnu.org/gnu/coreutils/
+
+* The comparison utilities 'cmp' and 'diff'.
+  + Mandatory. Using the platform's native utilities gives good portability
+exposure, but you can also use GNU diffutils.
+  + Homepage:
+https://www.gnu.org/software/diffutils/
+  + Download:
+https://ftp.gnu.org/gnu/diffutils/
+
+* Grep.
+  + Mandatory. Using the platform's native grep gives good portability
+exposure, but you can also use GNU grep.
+  + Homepage:
+https://www.gnu.org/software/grep/
+  + Download:
+http

Re: CI with clang 18 ?

[Collin Funk]

Bruno Haible  writes:

> In contrast, a CI build with the newest released gcc version seems
> less urgent, since
>   - Fedora jumps on the newest gcc quickly,
>   - gcc is not so frequently ahead of clang regarding ISO C language
> features.
> Right?
>
> Opinions?

Not sure about language standards but I know that Clang releases
sometimes introduce some warnings/errors which might be nice to see in
the logs.

It has been a while but I remember finding -Wtautological-* and
-Wbitwise-instead-of-logical to be annoying when they were introduced.

Do you know a way to get recent Clang binaries for the CI machines? From
what I remember the LLVM GitHub releases page only sometimes has common
platforms.

Collin

Re: CI with clang 18 ?

[Jim Meyering]

On Sat, Jul 13, 2024 at 12:16 AM Bruno Haible  wrote:
> I wrote:
> > so I can know why the CI did not report it within three weeks
>
> That was because the compilation error occurred only with clang 18,
> which was released in March 2024 and is therefore not yet present
> in the *BSD distros.
>
> In the last two years, I got the feeling that clang is adopting new
> ISO C features more quickly than GCC (seen with the K&R prototypes
> removal in clang 16, now with ckd_add in clang 18). So, would it
> make sense to do a CI build with the newest released clang version?
>
> In contrast, a CI build with the newest released gcc version seems
> less urgent, since
>   - Fedora jumps on the newest gcc quickly,
>   - gcc is not so frequently ahead of clang regarding ISO C language
> features.
> Right?
>
> Opinions?

It feels like a good thing to do, but will come with some cost: I have
the impression that relatively few GNU projects use clang (and esp
clang 18), so this testing is likely to expose more "issues". However,
a more diverse set of compilers/warnings may expose real problems in
our code sooner.

Re: CI with clang 18 ?

[Bruno Haible]

Jim Meyering wrote:
> It feels like a good thing to do, but will come with some cost: I have
> the impression that relatively few GNU projects use clang (and esp
> clang 18), so this testing is likely to expose more "issues". However,
> a more diverse set of compilers/warnings may expose real problems in
> our code sooner.

I'm not going to hunt down the warnings, only report the errors from the CI.

Yes, the idea is to expose the problems sooner. There is no reason why a
code change made in June 2024, that is reported by clang from March 2024
as an error in every 'testdir-all' build, needs to propagate into Emacs
until it gets noticed.

Bruno

Re: CI with clang 18 ?

[Bruno Haible]

Collin Funk wrote:
> Not sure about language standards but I know that Clang releases
> sometimes introduce some warnings/errors which might be nice to see in
> the logs.
> 
> It has been a while but I remember finding -Wtautological-* and
> -Wbitwise-instead-of-logical to be annoying when they were introduced.

No one will download the CI logs and grep them for warnings, probably.
Developers who want to listen to clang warnings typically do this on their
own machine, in an iterative process.

> Do you know a way to get recent Clang binaries for the CI machines? From
> what I remember the LLVM GitHub releases page only sometimes has common
> platforms.

There are clang+llvm binaries for 18.1.x [1] for x86_64-linux-gnu-ubuntu,
which is perfect for the CI machines (that are currently equipped with
Ubuntu 22.04). For other glibc platforms, I would build clang+llvm from
source. For *BSD platforms, I would wait on their "port".

Bruno

[1] https://github.com/llvm/llvm-project/releases/tag/llvmorg-18.1.8

Re: CI with clang 18 ?

[Bruno Haible]

Paul Eggert wrote:
> > In the last two years, I got the feeling that clang is adopting new
> > ISO C features more quickly than GCC (seen with the K&R prototypes
> > removal in clang 16, now with ckd_add in clang 18).
> 
> I don't have that feeling. I would put it differently, since GCC has 
> supported the ckd_add stuff for some time, and has merely been reluctant 
> to refuse to support K&R style function definitions (which C23 still 
> allows as an extension).
> 
> I would instead say that GCC is more willing to support C23 extensions 
> than Clang is.

Thanks; I stand corrected. So, we can say that clang switches to strict
interpretations of C23 sooner than gcc does.

This still is a sufficient rationale for doing a CI with the newest
released clang.

Bruno

Re: CI with clang 18 ?

[Collin Funk]

Bruno Haible  writes:

> There are clang+llvm binaries for 18.1.x [1] for x86_64-linux-gnu-ubuntu,
> which is perfect for the CI machines (that are currently equipped with
> Ubuntu 22.04). For other glibc platforms, I would build clang+llvm from
> source. For *BSD platforms, I would wait on their "port".

Sounds good. Though my machine always ran out of memory when compiling
LLVM unless I did 'ninja -j 1' so be careful. My system might just be
showing its age though.

Also, I just realized I had notifications for GitHub Actions turned off.
I turned them on so I should see failures when they happen.

Collin

stdlib: Support use of clang++ on Ubuntu

[Bruno Haible]

There are two ways to use the pre-built binaries of clang+llvm on a glibc
system, such as Ubuntu:

  a) Use CC=clang, CXX=clang++. This makes use of the clang++ runtime
 libraries. But AFAIU these are ABI-incompatible with the system's
 libstdc++ and thus with all other preinstalled libraries that use
 C++.

  b) Use CXX="clang++ -I/usr/include/c++/11 
-I/usr/include/x86_64-linux-gnu/c++/11 -L/usr/lib/gcc/x86_64-linux-gnu/11"
 with -I and -L options that ensure taht the system's libstdc++ gets
 used. So that it becomes ABI-compatible with preinstalled libraries.

The approach b) encounters a build a error in a testdir of all of gnulib,
however:

/home/bruno/inst-clang/18.1.4/bin/clang++ -I/usr/include/c++/11 
-I/usr/include/x86_64-linux-gnu/c++/11 -L/usr/lib/gcc/x86_64-linux-gnu/11 
-Wl,-rpath,/home/bruno/inst-clang/18.1.4/lib -DHAVE_CONFIG_H -DEXEEXT=\"\" 
-DEXEEXT=\"\" -I. -I../../gltests -I..  -DGNULIB_STRICT_CHECKING=1 
-DIN_GNULIB_TESTS=1 -I. -I../../gltests -I.. -I../../gltests/.. -I../gllib 
-I../../gltests/../gllib -I/media/develdata/devel/inst-x86_64-64/include -Wall  
-Wno-error -g -O2 -MT test-nullptr-c++.o -MD -MP -MF $depbase.Tpo -c -o 
test-nullptr-c++.o ../../gltests/test-nullptr-c++.cc &&\
mv -f $depbase.Tpo $depbase.Po
clang++: warning: -Wl,-rpath,/home/bruno/inst-clang/18.1.4/lib: 'linker' input 
unused [-Wunused-command-line-argument]
clang++: warning: argument unused during compilation: 
'-L/usr/lib/gcc/x86_64-linux-gnu/11' [-Wunused-command-line-argument]
../../gltests/test-nullptr-c++.cc:38:3: error: use of undeclared identifier 
'_gl_pre_abort'
   38 |   ASSERT (first[0] == 't');
  |   ^
../../gltests/macros.h:85:15: note: expanded from macro 'ASSERT'
   85 |   _gl_pre_abort (); 
 \
  |   ^
../../gltests/test-nullptr-c++.cc:42:3: error: use of undeclared identifier 
'_gl_pre_abort'
   42 |   ASSERT (arg == NULL);
  |   ^
../../gltests/macros.h:85:15: note: expanded from macro 'ASSERT'
   85 |   _gl_pre_abort (); 
 \
  |   ^
../../gltests/test-nullptr-c++.cc:45:3: error: use of undeclared identifier 
'_gl_pre_abort'
   45 |   ASSERT (arg[0] == 'f');
  |   ^
../../gltests/macros.h:85:15: note: expanded from macro 'ASSERT'
   85 |   _gl_pre_abort (); 
 \
  |   ^
../../gltests/test-nullptr-c++.cc:48:3: error: use of undeclared identifier 
'_gl_pre_abort'
   48 |   ASSERT (arg == NULL);
  |   ^
../../gltests/macros.h:85:15: note: expanded from macro 'ASSERT'
   85 |   _gl_pre_abort (); 
 \
  |   ^
4 errors generated.
make[4]: *** [Makefile:27303: test-nullptr-c++.o] Error 1


Where does this error come from?

  * When a #include  is encountered, gllib/stdlib.h is no
longer the first file in the "next" chain. But rather that chain
consists of
  1. /usr/include/c++/11/stdlib.h
  2. gllib/stdlib.h
  3. /usr/include/stdlib.h

  * At the first #include , __need_system_stdlib_h happens
to be set (by gllib/pthread.h), and so the bulk of gllib/stdlib.h
is bypassed.

  * Further #include  don't even reach gllib/stdlib.h, since
the file in position 1 (/usr/include/c++/11/stdlib.h), which does
not obey the __need_system_stdlib_h convention, expands to nothing.

  * Thus, the declaration of _gl_pre_abort in gllib/stdlib.h is never seen.

This patch fixes it.


2024-07-13  Bruno Haible  

stdlib: Support use of clang++ on Ubuntu.
* lib/stdlib.in.h: Ignore __need_system_stdlib_h when GCC's
c++/11/stdlib.h is being included or has been included.

diff --git a/lib/stdlib.in.h b/lib/stdlib.in.h
index cfc69d0a50..47a8856dc7 100644
--- a/lib/stdlib.in.h
+++ b/lib/stdlib.in.h
@@ -20,9 +20,18 @@
 #endif
 @PRAGMA_COLUMNS@
 
-#if defined __need_system_stdlib_h || defined __need_malloc_and_calloc
+#if (defined __need_system_stdlib_h && !defined _GLIBCXX_STDLIB_H) || defined 
__need_malloc_and_calloc
 /* Special invocation conventions inside some gnulib header files,
-   and inside some glibc header files, respectively.  */
+   and inside some glibc header files, respectively.
+   Do not recognize this special invocation convention when GCC's
+   c++/11/stdlib.h is being included or has been included. This is needed
+   to support the use of clang+llvm binaries on Ubuntu 22.04 with
+   CXX="$clangdir/bin/clang++ -I/usr/include/c++/11 \
+  -I/usr/include/x86_64-linux-gnu/c++/11
+  -L/usr/lib/gcc/x86_64-linux-gnu/11
+  -Wl,-rpath,$clangdir/lib"
+   because in this case /usr/include/c++/11/stdlib.h (which does not support
+   the convention) is seen before the gnulib-generated stdlib.h.  */
 
 #@INCLUDE_NEXT@ @NEXT_STDLIB_H@
 

Re: compiling LLVM

[Bruno Haible]

Collin Funk wrote:
> Though my machine always ran out of memory when compiling
> LLVM unless I did 'ninja -j 1' so be careful. My system might just be
> showing its age though.

It's not your system's age that is the problem. It's the C++ toolchains
(compiler and linker) that take a huge amount of memory. The compiler
is inundanted by megabytes of templates in .h files, and the linker
is inundanted by thousands of instantiations of the same templates
classes, each from a different compilation unit.

It's a known problem for GCC [1] and Firefox [2][3].

Bruno

[1] 
https://www.reddit.com/r/linuxmasterrace/comments/zhs2ag/building_gcc_on_1gb_of_ram/
[2] https://bbs.archlinux.org/viewtopic.php?id=290946
[3] https://www.youtube.com/watch?v=_hmMR0XooW4

announce-gen: Fix copyright year in --version output.

[Collin Funk]

The announce-gen and useless-if-before-free scripts have had changes
since their copyright date was updated:

$ ./build-aux/announce-gen --version
announce-gen version 2024-07-04 10:55
Copyright (C) 2022 Free Software Foundation, Inc.

I've pushed the two attached patches to derive the copyright year from
the time-stamp string.

Collin

>From 8b331b0f514e1eb9a2e46076b2ae6326751bb7c9 Mon Sep 17 00:00:00 2001
From: Collin Funk 
Date: Sat, 13 Jul 2024 20:10:46 -0700
Subject: [PATCH 1/2] announce-gen: Fix copyright year in --version output.

* build-aux/announce-gen (copyright_year): Derive from time-stamp.
---
 ChangeLog  | 5 +
 build-aux/announce-gen | 4 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index a97b22aa28..2ddb14c0db 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2024-07-13  Collin Funk  
+
+	announce-gen: Fix copyright year in --version output.
+	* build-aux/announce-gen (copyright_year): Derive from time-stamp.
+
 2024-07-13  Bruno Haible  
 
 	stdlib: Support use of clang++ on Ubuntu.
diff --git a/build-aux/announce-gen b/build-aux/announce-gen
index 9728aeee9e..a412853429 100755
--- a/build-aux/announce-gen
+++ b/build-aux/announce-gen
@@ -35,13 +35,13 @@
 eval 'exec perl -wSx "$0" "$@"'
  if 0;
 
-my $VERSION = '2024-07-04 10:55'; # UTC
+my $VERSION = '2024-07-14 03:11'; # UTC
 # The definition above must lie within the first 8 lines in order
 # for the Emacs time-stamp write hook (at end) to update it.
 # If you change this file with Emacs, please let the write hook
 # do its job.  Otherwise, update this string manually.
 
-my $copyright_year = '2022';
+(my $copyright_year = $VERSION) =~ s/^(\d*)-.*$/$1/;
 
 use strict;
 use Getopt::Long;
-- 
2.45.2

>From 1474f6fae39d03ffa04e443c616ec8fed179edd4 Mon Sep 17 00:00:00 2001
From: Collin Funk 
Date: Sat, 13 Jul 2024 20:14:22 -0700
Subject: [PATCH 2/2] useless-if-before-free: Fix copyright year in --version
 output.

* build-aux/useless-if-before-free (copyright_year): Derive from
time-stamp.
---
 ChangeLog| 4 
 build-aux/useless-if-before-free | 4 ++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 2ddb14c0db..56c0253f7a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,9 @@
 2024-07-13  Collin Funk  
 
+	useless-if-before-free: Fix copyright year in --version output.
+	* build-aux/useless-if-before-free (copyright_year): Derive from
+	time-stamp.
+
 	announce-gen: Fix copyright year in --version output.
 	* build-aux/announce-gen (copyright_year): Derive from time-stamp.
 
diff --git a/build-aux/useless-if-before-free b/build-aux/useless-if-before-free
index dde64ec215..39ce39ab31 100755
--- a/build-aux/useless-if-before-free
+++ b/build-aux/useless-if-before-free
@@ -36,13 +36,13 @@
 eval 'exec perl -wSx "$0" "$@"'
  if 0;
 
-my $VERSION = '2024-07-04 10:56'; # UTC
+my $VERSION = '2024-07-14 03:13'; # UTC
 # The definition above must lie within the first 8 lines in order
 # for the Emacs time-stamp write hook (at end) to update it.
 # If you change this file with Emacs, please let the write hook
 # do its job.  Otherwise, update this string manually.
 
-my $copyright_year = '2022';
+(my $copyright_year = $VERSION) =~ s/^(\d*)-.*$/$1/;
 
 use strict;
 use warnings;
-- 
2.45.2

Re: announce-gen: Fix copyright year in --version output.

[Bruno Haible]

Hi Collin,

> I've pushed the two attached patches to derive the copyright year from
> the time-stamp string.

> +(my $copyright_year = $VERSION) =~ s/^(\d*)-.*$/$1/;

Can this be rewritten in a simpler way, that does not use idioms
from perl's bag of tricks? Something like

  my $copyright_year = ;

like one would do it in every other programming language?

Thanks.

Bruno

Re: announce-gen: Fix copyright year in --version output.

[Collin Funk]

Hi Bruno,

Bruno Haible  writes:

> Can this be rewritten in a simpler way, that does not use idioms
> from perl's bag of tricks? Something like
>
>   my $copyright_year = ;
>
> like one would do it in every other programming language?

Not sure. I'm not the most knowledgeable perl programmer. Maybe
something like this is more clear?

my $copyright_year = (split ("-", $VERSION))[0];

or perhaps someone else has a better idea.

Collin