| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: killing perl2host |
| Date: | 2022-02-17 20:23:36 |
| Message-ID: | 31528c54-76c5-0b06-71d8-359c68ca04d5@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2/17/22 15:09, Andres Freund wrote:
> Hi,
>
> On 2022-02-17 14:40:01 -0500, Andrew Dunstan wrote:
>> Sure, that could be done, but what's the issue? Msys2 normally defines
>> MSYSTEM for you - see /etc/msystem which is sourced by /etc/profile.
> It seems not a great idea to me to use different sources of truth about build
> target. And I think it's not hard to get the actual host_os and MSYSTEM to
> disagree:
> - afaics it's quite possible to run configure outside of a login msys shell
> - you could do an msys build in a ucrt shell, but specify --host=x86_64-pc-msys,
> or the other way round
Very well. I think the easiest way will be to stash $host_os in the
environment and let the script pick it up similarly to what I suggested
with MSYSTEM.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2022-02-17 20:46:27 | Re: killing perl2host |
| Previous Message | Robert Haas | 2022-02-17 20:22:08 | Re: buildfarm warnings |