On Tue, Mar 19, 2024 at 01:04:30PM +0000, Dima Pasechnik wrote: > On Mon, Mar 18, 2024 at 11:08 PM Waldek Hebisch <[email protected]> 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 -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZfttL3AzrfUEsOBl%40fricas.org.
