guile-devel
[Top][All Lists]
Advanced

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

Re: what to do about gnulib


From: Andy Wingo
Subject: Re: what to do about gnulib
Date: Mon, 24 Jun 2024 22:59:49 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Hi Bruno!

Thanks for your kind answer and tips :)

On Mon 24 Jun 2024 19:09, Bruno Haible <bruno@clisp.org> writes:

> I can reproduce a problem by
>   0. using a git checkout of guile ('main' branch, not 'master' branch),
>   1. using a GNU gettext version 0.22.5, 0.21, 0.20.2, or 0.19.8.1,
>   2. removing the gnulib-local/m4/clock_time.m4.diff file, which no longer
>      applies,
>   3. running
>      $ $GNULIB_SRCDIR/gnulib-tool --update
>   4. running
>      $ ./autogen.sh
>      (which is what the HACKING file recommends).
>
> It fails with
>
> configure:12833: error: possibly undefined macro: gl_PTHREADLIB
>       If this token and others are legitimate, please use m4_pattern_allow.
>       See the Autoconf documentation.
> configure:12943: error: possibly undefined macro: gl_WEAK_SYMBOLS
> configure:27584: error: possibly undefined macro: gl_TYPE_WINT_T_PREREQ
> autoreconf: error: /usr/bin/autoconf failed with exit status: 1
>
> Following your analysis, I locally apply the workaround from the Gnulib
> documentation section "3.11 Caveat: gettextize and autopoint users",

Thank you!  It is embarrassing but I did not know this manual existed.
I will use this workaround.

Question, do you think it would be reasonable for autopoint to avoid
overwriting newer files?  It seems like the sort of problem we could
avoid, but who knows.

>   373 | unreachable (scm_jit_state *j)

Ah interesting, will fix.

> The way Guile handles versioning of Gnulib-imported files is fine.

That's great to hear.  In that case, no change planned to how we do
things.

> Note, though, that the imported po/ infrastructure will still be from 2010,
> due to this line in configure.ac:
>   AM_GNU_GETTEXT_VERSION([0.18.1])
> It would be reasonable to bump this version specification to
>   AM_GNU_GETTEXT_VERSION([0.19.8.1])
> (from 2016) or
>   AM_GNU_GETTEXT_VERSION([0.20.2])
> (from 2020) or
>   AM_GNU_GETTEXT_VERSION([0.21.1])
> (from 2022).
>
> Note also that when upgrading to a newer Gnulib, you now have another choice
> than Gnulib's 'master' branch: the 'stable-202401' branch. See the Gnulib
> documentation [2], section "1.6.1 Stable Branches".

Thanks!!

Best regards,

Andy



reply via email to

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