update autoconf stuff

[Qian Yun]

I see that "configure" is updated in branch r1.3.10 by
autoconf 2.71. I suggest we do the same for master branch.
(Using 2.71 or 2.72 is debatable.)

Also, we can update various files under "config/". Although
it is not required for the arm64 mac build. But they have
not been updated for a very very long time.

It can be updated by:

https://www.gnu.org/software/gettext/manual/html_node/config_002eguess.html

wget -O config.guess
'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD'
wget -O config.sub
'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD'


And "install-sh missing mkinstalldirs" is provided by automake.

- Qian

[Dima Pasechnik]

On Mon, Mar 18, 2024 at 2:39 PM Qian Yun <oldk...@gmail.com> wrote:

I see that "configure" is updated in branch r1.3.10 by
autoconf 2.71.  I suggest we do the same for master branch.
(Using 2.71 or 2.72 is debatable.)

2.72 is a bugfix release, so it's better to use it

 

Also, we can update various files under "config/".  Although
it is not required for the arm64 mac build.  But they have
not been updated for a very very long time.

It can be updated by:

https://www.gnu.org/software/gettext/manual/html_node/config_002eguess.html

wget -O config.guess
'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD'
wget -O config.sub
'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD'


And "install-sh  missing  mkinstalldirs" is provided by automake.

- Qian

--
You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/485e0839-b320-4a6a-aca8-1979fb7ee72a%40gmail.com.

[Waldek Hebisch]

On Mon, Mar 18, 2024 at 10:33:09PM +0000, Dima Pasechnik wrote:
> On Mon, Mar 18, 2024 at 2:39 PM Qian Yun <oldk...@gmail.com> wrote:
>
> > I see that "configure" is updated in branch r1.3.10 by
> > autoconf 2.71. I suggest we do the same for master branch.
> > (Using 2.71 or 2.72 is debatable.)
> >
>
> 2.72 is a bugfix release, so it's better to use it

We use autoconf from the system on which it is run. Currently
Debian stable uses autoconf 2.71. To use different version of
autoconf would require strong reason, like bug in Debian 2.71 which
affect our use fixed in later version. I am not aware of anything
like this.

--
Waldek Hebisch

[Waldek Hebisch]

On Mon, Mar 18, 2024 at 10:39:05PM +0800, Qian Yun wrote:
> I see that "configure" is updated in branch r1.3.10 by
> autoconf 2.71. I suggest we do the same for master branch.
> (Using 2.71 or 2.72 is debatable.)

Well, 'configure' is supposed to be portable. We update it
when there is a need. Since for release 'configure' contains
version number each release needs its own 'configure'. ATM
I see no reason to regenerate 'configure' in the trunk.

> Also, we can update various files under "config/". Although
> it is not required for the arm64 mac build. But they have
> not been updated for a very very long time.

This is slowly changing stuff. AFAICS upstream changes are
mostly churn. In the future we probably will need RISC-V stuff,
but it does not look urgent.

>
> It can be updated by:
>
> https://www.gnu.org/software/gettext/manual/html_node/config_002eguess.html
>
> wget -O config.guess 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD'
> wget -O config.sub 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD'
>
>
> And "install-sh missing mkinstalldirs" is provided by automake.

Note that we _do not_ use automake and I very much prefer to avoid it
(and related bloat).

--
Waldek Hebisch

[Qian Yun]

On 3/19/24 07:08, Waldek Hebisch wrote:
> On Mon, Mar 18, 2024 at 10:39:05PM +0800, Qian Yun wrote:
>> I see that "configure" is updated in branch r1.3.10 by
>> autoconf 2.71. I suggest we do the same for master branch.
>> (Using 2.71 or 2.72 is debatable.)
>
> Well, 'configure' is supposed to be portable. We update it
> when there is a need. Since for release 'configure' contains
> version number each release needs its own 'configure'. ATM
> I see no reason to regenerate 'configure' in the trunk.

On the related subject, I suggest that 'configure' use git hash
as version number instead of current date. What's your thoughts?

>> Also, we can update various files under "config/". Although
>> it is not required for the arm64 mac build. But they have
>> not been updated for a very very long time.
>
> This is slowly changing stuff. AFAICS upstream changes are
> mostly churn. In the future we probably will need RISC-V stuff,
> but it does not look urgent.

There are certainly improvements and fixes, and low risk of bugs.

I glanced the changelog, and found this useful commit:

https://git.savannah.gnu.org/gitweb/?p=config.git;a=commitdiff;h=ca9bfb8cc75a2be1819d89c664a867785c96c9ba

* config.guess (x86_64:Linux:*:*): Output 'pc', not 'unknown'.

You used to manually remove the "unknown" part. Now it is gone.

>>
>> It can be updated by:
>>
>> https://www.gnu.org/software/gettext/manual/html_node/config_002eguess.html
>>
>> wget -O config.guess 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD'
>> wget -O config.sub 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD'
>>
>>
>> And "install-sh missing mkinstalldirs" is provided by automake.
>
> Note that we _do not_ use automake and I very much prefer to avoid it
> (and related bloat).
>

I mean that config/install-sh is from automake repo:

https://git.savannah.gnu.org/cgit/automake.git/log/lib/install-sh

The changelog seems to include some minor fixes.

Our version is from 2005...

- Qian

[Dima Pasechnik]

On Mon, Mar 18, 2024 at 11:08 PM Waldek Hebisch <de...@fricas.org> wrote:

On Mon, Mar 18, 2024 at 10:39:05PM +0800, Qian Yun wrote:
> I see that "configure" is updated in branch r1.3.10 by
> autoconf 2.71.  I suggest we do the same for master branch.
> (Using 2.71 or 2.72 is debatable.)

Well, 'configure' is supposed to be portable.  We update it
when there is a need.  Since for release 'configure' contains
version number each release needs its own 'configure'.  ATM
I see no reason to regenerate 'configure' in the trunk.

after ./configure et al. are generated, it's all portable.

One immediate reason to use 2.72 is correct year 2038 support (something which

boils down to how time_t behaves on 32-bit systems).

E.g. recently I had some fun with porting nauty to modern autoconf:

https://bugs.gentoo.org/921138

> Also, we can update various files under "config/".  Although
> it is not required for the arm64 mac build.  But they have
> not been updated for a very very long time.

this is not true. E.g. the log for config/configure.sub and config.guess shows a number of updates in last year, this year, and more since 2020 (after a gap in 2017-2019)

http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=history;f=build-aux/config.sub;h=2c6a07ab3c34eabed8318ec0a37c0cc23b77a63f;hb=HEAD

http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=history;f=build-aux/config.guess;h=f6d217a49f8f4a664e1437306f3c4196793dcb35;hb=HEAD

(yes, a lot of it  are just dates bumps, but there a very meaningful changes too)

 

This is slowly changing stuff.  AFAICS upstream changes are
mostly churn.  In the future we probably will need RISC-V stuff,
but it does not look urgent.

 

Well, it is urgent.

I know people already running Risc-V boads, and I'm getting one soon, too.

 

>
> It can be updated by:
>
> https://www.gnu.org/software/gettext/manual/html_node/config_002eguess.html
>
> wget -O config.guess 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD'
> wget -O config.sub 'https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD'
>
>
> And "install-sh  missing  mkinstalldirs" is provided by automake.

Note that we _do not_ use automake and I very much prefer to avoid it
(and related bloat).

sure - but there are things, such as config.rpath, which ended up in automake at some point;

the right way to get them into the code, but avoid automake, is by using gnulib.

Does fricas use gnulib?

(yes, Sage used to "manually" copy files from automake, but we switched to using gnulib,

which basically means to run it once every few years, check files it generates into the git repo, and update what it produces, if needed)

Dima

[Waldek Hebisch]

On Tue, Mar 19, 2024 at 01:04:30PM +0000, Dima Pasechnik wrote:
> On Mon, Mar 18, 2024 at 11:08 PM Waldek Hebisch <de...@fricas.org> wrote:
>
> > On Mon, Mar 18, 2024 at 10:39:05PM +0800, Qian Yun wrote:
> > > I see that "configure" is updated in branch r1.3.10 by
> > > autoconf 2.71. I suggest we do the same for master branch.
> > > (Using 2.71 or 2.72 is debatable.)
> >
> > Well, 'configure' is supposed to be portable. We update it
> > when there is a need. Since for release 'configure' contains
> > version number each release needs its own 'configure'. ATM
> > I see no reason to regenerate 'configure' in the trunk.
> >
>
> after ./configure et al. are generated, it's all portable.
> One immediate reason to use 2.72 is correct year 2038 support (something
> which
> boils down to how time_t behaves on 32-bit systems).

I am not sure what is now considerd as "correct year 2038 support".
AFAICS 95% of programs can live with windowed comparisons, that
is use 32-bit time and consider it as relative to "now". Some
programs will need 64-bit time. That looks mostly as something
that individual program need to sort out. Autoconf does not look
like significant part of solution, except that OS/libraries can
offer different level of support and autoconf can help with
dealing with resulting mess.

AFAICS currently FriCAS assumens that 'time_t' will work correctly.
Depending on what OS/libraries do this may be no longer true after
2038. We have still few years to resolve this. To say the truth
I am not sure if in 2038 we will care about 32-bit systems (I certainly
care _today_ about 32-bit systems).

> E.g. recently I had some fun with porting nauty to modern autoconf:
> https://bugs.gentoo.org/921138

Hmm, AFAICS nauty depended on autoconf internals and got broken
by autoconf change. If goal it to fix nauty, then trying with
newer autoconf allow early detection of errors. OTOH if goal is
to just build nauty, then it makes sense to continue with old
autoconf (or old generated configure stuff).

> > This is slowly changing stuff. AFAICS upstream changes are
> > mostly churn. In the future we probably will need RISC-V stuff,
> > but it does not look urgent.
> >
>
> Well, it is urgent.
> I know people already running Risc-V boads, and I'm getting one soon, too.

I have Risc-V board. But I admit that till now I did not use it.
I not in the mood of dealing with kernel/libc and it looked that
software support was still in stage of resolving very basic troubles
and not ready for higher level developement.

>
> sure - but there are things, such as config.rpath, which ended up in
> automake at some point;
> the right way to get them into the code, but avoid automake, is by using
> gnulib.
> Does fricas use gnulib?

No.

--
Waldek Hebisch