Collin Funk writes:
> $ gcc --version
> gcc (OmniOS 151052/14.2.0-il-1) 14.2.0
I was wondering why this failure didn't occur in the GitHub CI. It is
because the CI uses GCC 13 where it is a warning. In GCC 14 they made it
an error by default (-Werror=incompatible-pointer-types) [1].
Col
On OmniOS a testdir of all modules fails to build like so:
$ uname -a
SunOS omnios 5.11 omnios-r151052-dbe4644ba92 i86pc i386 i86pc
$ gcc --version
gcc (OmniOS 151052/14.2.0-il-1) 14.2.0
$ ./configure
$ make
[...]
gcc -std=gnu23 -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEX
Basil L. Contovounesios wrote:
> > The fix is to add a definition
> >ACLOCAL_AMFLAGS = -I m4
> ...
> Do you know what it is about the new git-version-gen approach that gives
> rise to this? The redundant ACLOCAL_AMFLAGS were not needed with the
> previously documented approach.
The other *.m4
Bruno Haible [2025-01-23 21:47 +0100] wrote:
> Yes, and I hope that once the approach to let 'git-version-gen' be run
> at configure time (as opposed to autoconf time) is more widely accepted,
You have my vote ;).
>> IIUC this is because Gnulib's build-aux/bootstrap looks at AC_INIT
>> argum
Simon Josefsson wrote:
> > Yes, and I hope that once the approach to let 'git-version-gen' be run
> > at configure time (as opposed to autoconf time) is more widely accepted,
>
> Oh! Is that changed now?
Yes. It should have been clear from the list of fixes [1] and from the
new documentation (no
Bruno Haible via Gnulib discussion list writes:
>> From reading Gnulib's m4/init-package-version.m4 commentary I can
>> appreciate that it's a delicate dance
>
> Yes, and I hope that once the approach to let 'git-version-gen' be run
> at configure time (as opposed to autoconf time) is more wi
Simon Josefsson wrote:
> I had the same thoughts as you on the '*-dirty' keyword.
Thanks for mentioning it.
> However there is a subtlety: modifying a git-owned files lead to version
> changes, which after "make dist" in most projects leads to many files
> being different compared to upstream ver
Hi Basil,
Thanks for the feedback.
> > +One such propagated value is
> > +the value of the Automake-defined variable @code{$(VERSION)}.
> > +(There is also the Autoconf-defined variable @code{$(PACKAGE_VERSION)},
> > +but nothing except Automake ought to use it.)
>
> Why ought nothing else use P
Bruno Haible via Gnulib discussion list [2025-01-22 21:53 +0100] wrote:
> Spent the day thinking through the concepts and fixing all the problems.
Thank you for working on this!
I'm facing the following issues in adapting my project to the new
git-version-gen guidelines.
I've pushed a stripped-
