[m-rev.] for review: Make gcc and clang version checks more robust.

[Julien Fischer]

On Wed, 20 Dec 2023, Peter Wang wrote:

> On Wed, 20 Dec 2023 14:54:52 +1100 Julien Fischer <jfischer at opturion.com> wrote:
>>
>> On Tue, 19 Dec 2023, Peter Wang wrote:
>>
>>> {x86_64,i686}-w64-mingw32-gcc -dumpfullversion on Debian 12
>>> reports "12-win32", which the MERCURY_GCC_VERSION macro failed
>>> to parse, as it expected a minor version to be present.
>>
>> Really? Whose idea was that?!? That isn't the documented behaviour
>> of that option.
>
> I can't make sense of Debian packaging, but I suspect that's where to
> look.

The documentation says that output should consist of three numbers
separated by periods.  If Debian are doing something different, they've
broken it. (It's a stupid thing to do anyway, since -dumpmachine tells
you what the target machine is.)

>>> m4/mercury.m4:
>>>    In the MERCURY_GCC_VERSION macro:
>>>      - simplify calling $CC -dumpfullversion or $CC -dumpversion
>>>      - trim any suffix following a hyphen in the raw gcc version output
>>>      - set major/minor/patchlevel fields containing anything
>>>        other than a sequence of decimal digits to "u"
>>>      - use $() syntax for command substitutions
>>>
>>>    Modify the MERCURY_CLANG_VERSION macro in a similar way.
>>
>> That's fine.
>
> I shouldn't have added quotes around $CC, in case CC includes options
> (which is more likely than the path to the C compiler containing spaces,
> on Unix at least).

Yes, you're right. And CC is sometimes set to things like "gcc -m32".
(Although, not so much these days.)

Julien.