On Mon, May 29, 2017 at 5:06 PM, Michał Górny <mgo...@gentoo.org> wrote:
> On pon, 2017-05-29 at 16:58 -0400, Mike Gilbert wrote:
>> + # system roughly corresponds to uname -s (lowercase)
>> + local system=unknown
>> + case ${CHOST} in
>> + *-aix*) system=aix ;;
>> + *-cygwin*) system=cygwin ;;
>> + *-darwin*) system=darwin ;;
>> + *-freebsd*) system=freebsd ;;
>> + *-linux*) system=linux ;;
>> + *-solaris*) system=sunos ;;
>
> Don't you want to die on unknown system? Or is it likely to work anyway?
Good question.
The 'system' property controls some built-in logic in meson itself
(mainly for MS Windows), and may be referenced by project files as
'host_machine.system()'. Setting it to 'unknown' may cause failures
for projects that actually look at it.
However, I think most projects would work without having this set to a
known value.
>> + esac
>> +
>> + local cpu_family=$(tc-arch)
>> + case ${cpu_family} in
>> + amd64) cpu_family=x86_64 ;;
>> + arm64) cpu_family=aarch64 ;;
>
> That's purely mapping from known-wrong values, correct? Maybe it'd be
> reasonable to assert for all correct too, and fail on unknown?
Yes, it corrects two obvious deviations from uname -m on Linux. x86 is
ok since that is what meson expects/generates for i?86.
I'm not sure what you mean by "assert for all correct"; if you mean
check for all valid values for cpu_family, such a list does not exist.
Similar to 'system' this property may or may not be used depending on
the project. Defaulting to "unknown" should be fine in many cases. I
don't think we need to fail.
>> + # Both meson(1) and _meson_create_cross_file need these
>> + tc-export AR CC CXX STRIP
>
> Wouldn't it be reasonable to make them local first anyway? I would try
> to avoid polluting the environment.
Makes sense. I'll revise this to "local -x CC=$(tc-getCC)", etc.
