Update CDDLIB source package? (was: What is the correct way to patch packages that use autotools?)

[Erik Bray]

On Thu, Nov 17, 2016 at 5:28 PM, Jean-Pierre Flori <jpf...@gmail.com> wrote:
>
>
> On Thursday, November 17, 2016 at 5:27:15 PM UTC+1, Erik Bray wrote:
>>
>> Hmm, okay. I am using my system's autoreconf. For the sage autotools
>> is that just an optional package I need to install?
>
> Yes.

Well, this is still turning out to be a bust, even using Sage's
autotools package. I'm trying to reconfigure CDDLIB and its
configure.in is not compatible in many ways with the versions of the
tools it wants to use. For example, its Makefile.in says it was
generated by automake 1.10.3, so it's trying to use automake 1.10.3
(along the same lines, it's using autoconf 2.63 and libtool 2.2.6b)

Even if I take the existing source package, without any of my own
changes (but with the patches in the spkg), when I naively try to run
autoreconf I get:

$ autoreconf -v -f -i
autoreconf: Entering directory `.'
autoreconf: configure.in: not using Gettext
autoreconf: running: aclocal --force
main::scan_file() called too early to check prototype at
/home/embray/src/sagemath/sage/local/automake-1.10.3/bin/aclocal line
617.
autoreconf: configure.in: tracing
autoreconf: configure.in: not using Libtool
autoreconf: running:
/home/embray/src/sagemath/sage/local/autoconf-2.69/bin/autoconf
--force
autoreconf: configure.in: not using Autoheader
autoreconf: running: automake --add-missing --copy --force-missing
Unescaped left brace in regex is deprecated, passed through in regex;
marked by <-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at
/home/embray/src/sagemath/sage/local/automake-1.10.3/bin/automake line
3832.
lib-src-gmp/Makefile.am:1: Libtool library used but `LIBTOOL' is undefined
lib-src-gmp/Makefile.am:1: The usual way to define `LIBTOOL' is to
add `AC_PROG_LIBTOOL'
lib-src-gmp/Makefile.am:1: to `configure.in' and run `aclocal' and
`autoconf' again.
lib-src-gmp/Makefile.am:1: If `AC_PROG_LIBTOOL' is in
`configure.in', make sure
lib-src-gmp/Makefile.am:1: its definition is in aclocal's search path.
lib-src/Makefile.am:1: Libtool library used but `LIBTOOL' is undefined
lib-src/Makefile.am:1: The usual way to define `LIBTOOL' is to add
`AC_PROG_LIBTOOL'
lib-src/Makefile.am:1: to `configure.in' and run `aclocal' and
`autoconf' again.
lib-src/Makefile.am:1: If `AC_PROG_LIBTOOL' is in `configure.in', make sure
lib-src/Makefile.am:1: its definition is in aclocal's search path.
autoreconf: automake failed with exit status: 1

The bare minimum I had to do to make it work was to add

AC_CONFIG_MACRO_DIR([m4])

to the configure.in, re-ran libtoolize, and then

$ AUTOMAKE_VERSION=1.14.1 AUTOCONF_VERSION=2.65 autoreconf -fiv

This at least resulted in a seemingly working configure and Makefile.
But all the generated files are now significantly updated.

IIUC we're basically the only ones maintaining CDDLIB anyways, so
should I just build a new upstream package for it with my fixes?

Thanks,
Erik

[Dima Pasechnik]

UANUC: see

https://www.inf.ethz.ch/personal/fukudak/cdd_home/

for cddlib version 0.94h, (released in April 2015)---newer than what we ship.

We should upgrade...

[Erik Bray]

Okay, but according to the changelog in 0.94h the only change is:

"Thanks to Mathieu Dutour, one minor bug has been fixed."

It doesn't say what the bug is. None of the autotools files have been
updated and are still basically broken.

[Dima Pasechnik]

I merely meant to say that it is still maintained by its creator.

I am sure he would appreciate a meaningful patch, too.

 

[Francois Bissey]

configure.in are certainly a bad indicator. Anything with one
of these instead of configure.ac triggers a warning in gentoo
that support for it will be dropped sooner than later.

In any case what kind of changes do you want to apply, I
may have better luck with my packaging machinery.

François

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

[Jean-Pierre Flori]

We should definitely contact upstream if updating the autotools stuff there is needed.

[Jean-Pierre Flori]

On Wednesday, November 23, 2016 at 12:17:08 PM UTC+1, Jean-Pierre Flori wrote:

We should definitely contact upstream if updating the autotools stuff there is needed.

But do they ship autotools stuff or does it come from Sage?

Old tickets:
* https://trac.sagemath.org/ticket/13026
* https://trac.sagemath.org/ticket/15871

[Erik Bray]

On Wed, Nov 23, 2016 at 12:13 PM, Francois Bissey
<francoi...@canterbury.ac.nz> wrote:
> configure.in are certainly a bad indicator. Anything with one
> of these instead of configure.ac triggers a warning in gentoo
> that support for it will be dropped sooner than later.

Yes, I get that warning as well. It's mostly superficial (for now)
but what's worse is that it doesn't even work with the version of
automake (which sage's autofoo tries to use) that was last used to
generate the Makefile.ins.

> In any case what kind of changes do you want to apply, I
> may have better luck with my packaging machinery.

These are the specific changes I need for Windows:

https://trac.sagemath.org/ticket/15872

Other than that it needs the updating I mentioned in this thread, at a
bare minimum (and probably to rename configure.in to configure.ac as
well).

Thanks,
Erik

[Erik Bray]

That's what I was unclear about. I saw those tickets and assumed that
we had been messing with the autotools stuff, and wasn't sure if it
was still maintained by its creator. But the upstream source tarball
contains the same autotools files so maybe we upstreamed that at some
point, but it originated from Sage....?

I don't know. It doesn't say in the changelog.

[Jean-Pierre Flori]

From what I see, the current situation is still a mess.
Yes upstream ships an autotool build system but we heavily patch it.
We should definitely exchange with them.

[Dima Pasechnik]

AFAIK (20+ years experience with (lib)CDD ;-)) autotools support was donated to cdd many years ago, at 2001, 

and it predates Sage.

I'm sure updates would be welcome.

[Erik Bray]

On Wed, Nov 23, 2016 at 12:58 PM, Dima Pasechnik <dim...@gmail.com> wrote:
> AFAIK (20+ years experience with (lib)CDD ;-)) autotools support was donated
> to cdd many years ago, at 2001,
> and it predates Sage.
> I'm sure updates would be welcome.

Alright, thanks for the history. I knew there were some pages that
Sage did autotoolize, and I wasn't sure whether or not this was one of
them.

I'll put together some patches to clean things up and send upstream :)

> On Wednesday, November 23, 2016 at 11:40:07 AM UTC, Jean-Pierre Flori wrote:
>>
>>
>>
>> On Wednesday, November 23, 2016 at 12:24:43 PM UTC+1, Erik Bray wrote:
>>>
>>> On Wed, Nov 23, 2016 at 12:19 PM, Jean-Pierre Flori <jpf...@gmail.com>
>>> wrote:
>>> >
>>> >
>>> > On Wednesday, November 23, 2016 at 12:17:08 PM UTC+1, Jean-Pierre Flori
>>> > wrote:
>>> >>
>>> >> We should definitely contact upstream if updating the autotools stuff
>>> >> there is needed.
>>> >
>>> > But do they ship autotools stuff or does it come from Sage?
>>> >
>>> > Old tickets:
>>> > * https://trac.sagemath.org/ticket/13026
>>> > * https://trac.sagemath.org/ticket/15871
>>>
>>> That's what I was unclear about. I saw those tickets and assumed that
>>> we had been messing with the autotools stuff, and wasn't sure if it
>>> was still maintained by its creator. But the upstream source tarball
>>> contains the same autotools files so maybe we upstreamed that at some
>>> point, but it originated from Sage....?
>>>
>>> I don't know. It doesn't say in the changelog.
>>
>> From what I see, the current situation is still a mess.
>> Yes upstream ships an autotool build system but we heavily patch it.
>> We should definitely exchange with them.
>>