optional package autotools fail to build

[vdelecroix]

At least on archlinux

autoreconf: running: automake-1.10 --add-missing --copy
Useless use of /d modifier in transliteration operator at /opt/sage/local/var/tmp/sage/build/autotools-20141105.p0/build/automake-1.10/lib/Automake/Wrap.pm line 60.
Unescaped left brace in regex is illegal here in regex; marked by <-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at /opt/sage/local/var/tmp/sage/build/autotools-20141105.p0/build/automake-1.10/automake line 3823.
autoreconf: automake-1.10 failed with exit status: 255
make[4]: *** [Makefile:665: amhello-1.0.tar.gz] Error 1

The branch attached to this ticket proposes to drop this SPKG.

[vbraun]

Optional packages aren't release blockers

[mkoeppe]

It may be worth checking whether the approach of this package, namely to build ALL versions of the autotools, is still necessary. Perhaps it's better to just replace it by a simple package that builds a set of recent versions. If there are sage packages that really need a specific set of autotools versions, that's something that can be fixed by patching (and sending these patches upstream).

[saraedum]

From the SPKG.txt file it does not seem that this was to make packages work that need a specific version of autotools. Rather the idea was to use the same version of autotools that was used to create the original configure and friends when patching something like configure.in. This keeps the patches small.

I can see why this was done and this is certainly a nice idea but I am not sure it warrants this package in Sage. The configure file is generated, so shouldn't we just trust a recent version of autotools and try to make our changes to configure.in small?

Anyway, the autotools SPKG does not build for me. I can not remove the offending versions of automake because the ./spkg-write-makefile script needs the autotools SPKG to be installed already.

[saraedum]

It appears that Perl has changed how it handles unescaped braces, ​https://stackoverflow.com/questions/43165604/unescaped-left-brace-regex-error. This used to be deprecated and probably it's an error now. My perl is 5.26.1 (archlinux.)

I'll try to install an old perl and drop the problematic versions of automake.

[saraedum]

With an older perl (5.24.1) I only get a deprecation:

Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at /home/jule/proj/sage/sage/local/automake-1.10/bin/automake line 3823.

[saraedum]

The issue is fixed in automake since this commit which is in 1.15.1+.

commit 13f00eb4493c217269b76614759e452d8302955e
Author: Paul Eggert <eggert@cs.ucla.edu>
Date:   Thu Mar 31 16:35:29 2016 -0700

    automake: port to Perl 5.22 and later
    
    Without this change, Perl 5.22 complains "Unescaped left brace in
    regex is deprecated" and this is planned to become a hard error in
    Perl 5.26.  See:
    http://search.cpan.org/dist/perl-5.22.0/pod/perldelta.pod#A_literal_%22{%22_should_now_be_escaped_in_a_pattern
    * bin/automake.in (substitute_ac_subst_variables): Escape left brace.

So that means that everything between 1.10 and 1.15 is affected.

[saraedum]

mkoeppe: What should we do now?

1. Drop the affected versions? (that's the easiest I think)
2. Just package recent versions as you proposed earlier.
3. Package none at all, and just expect people to have recent autotools (I think that's better than 2 actually.)
4. Cherry-pick the fixing commit into every tag and make this SPKG more complicated than it is already.
5. ?

[embray]

I've found it somewhat convenient that this makes it easy to install multiple autoconf/automake versions side-by-side, which isn't always as easy to do at the system level. It's rare that I've needed to do this--as you mentioned earlier it's if I've had to patch something in package's configure.ac and generate a new configure while keeping the patch itself comprehensible.

That said, I don't think this is all that important either. As long as the patch made to configure.ac is small I don't think we care about the size of the patch to the configure script itself.

Considering the trouble it's becoming, I'm also in favor of just dropping support for the autotools SPKG. It's not worth the effort to maintain, and its purpose can be fulfilled in other ways.

[saraedum]

New commits:

​ef59eba

Drop optional autotools SPKG

[saraedum]

Downgrading as many distributions (such as Debian) are not yet affected.

[saraedum]

How should I test that this does not break anything? Rebuild from scratch?

[dimpase]

the original purpose of this package is to provide some autotool version in situations where there is none, e.g. on OSX.

building autotools from scratch is not very straightforward, e.g. I recall needing once to build a newer m4 to build it, etc etc.

I think it either should be dropped or fixed to work on all platforms.

I guess we might need a vote on sage-devel in order to drop it.

[saraedum]

Is autotools not available with brew on OSX now? Otherwise it should also be available with conda.

[dimpase]

I don't know whether it is available with either of them, what is known is that neither of them work with Sage.

That is, building/running Sage in either of these environments does not work.

Yes, probably one can run Sage's ./bootstrap in either of them, then uninstall them and proceed with building Sage :-)

[saraedum]

Replying to dimpase:

I don't know whether it is available with either of them, what is known is that neither of them work with Sage.

That is, building/running Sage in either of these environments does not work.

I don't have OSX here but why would Sage not build if conda's autotools are on the path? At least at conda-forge's ​https://github.com/conda-forge/sagelib-feedstock/ we do not do any autools related patching as far as I know.

Yes, probably one can run Sage's ./bootstrap in either of them, then uninstall them and proceed with building Sage :-)

That sounds like it would be a quite annoying workflow. But you would only have to do that when you change configure.ac and such, right?

[dimpase]

Optional packages that are broken on some arcs are to be downgraded to experimental. We can do this, for sure.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​a7cf452	Revert "Drop optional autotools SPKG"
​76732a4	Make autotools experimental

[saraedum]

Ok. Do we need a vote for downgrading this to experimental?

[dimpase]

Replying to saraedum:

Ok. Do we need a vote for downgrading this to experimental?

a package that is broken somehow downgrades itself.