[m-users.] 22.01 beta release available

[Fabrice Nicol]

OK, so why test for a bootstapping compiler (configure.ac: 386-646) if it
is not useful at all -- I mean in the case of building an ROTD?
This configure step strikes me as a source of possible building issues for
ROTDs / releases.
In case that a slightly older yet "broken" Mercury compiler is in the PATH,
configure will fail, whereas it would build fine with a clean PATH. (This
is *not* what happened in my prior alert, but I stumbled into this a year
ago).

Why not deactivate this configure.ac chunk out of ROTDs, perhaps by
enforcing BOOTSTRAP_MC="", instead of AC_PATH_PROG(BOOTSTRAP_MC, mmc) in
configure.ac:376?
As long as mercury_compile.c is shipped with ROTDs, this AC_PATH_PROG m4
macro is only useful for building the git source code.


Le dim. 23 janv. 2022 à 11:39 PM, Zoltan Somogyi <zoltan.somogyi at runbox.com>
a écrit :

>
> 2022-01-24 09:32 GMT+11:00 "Fabrice Nicol" <fabrnicol at gmail.com>:
> > This is because you have relatively fresh,  intermediate bootstrapping
> > compilers that enable you to build ROTDs. Once in a while, this build
> chain
> > breaks down unless you update your bootstrapping compiler itself.
>
> No, he is right; I was wrong. You are right that if you want to compile an
> ROTD
> from Mercury to executable, you need a recent Mercury compiler, and this is
> indeed what I was thinking of when I sent my original email, but he is
> also right
> in that you do not *have to* compile ROTDs from Mercury: because they ship
> with pre-built .c files, you do not need a working Mercury compiler at all.
> (Unless of course some internet gremlin mangles those .c files.)
>
> Zoltan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20220124/37117291/attachment.html>