Re: Mixing CC and a different CLANG seems like a bad idea - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Mixing CC and a different CLANG seems like a bad idea
Date
Msg-id 20211118213435.dnpyrnlkg3k7vnak@alap3.anarazel.de
Whole thread Raw
In response to Re: Mixing CC and a different CLANG seems like a bad idea  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Mixing CC and a different CLANG seems like a bad idea
List pgsql-hackers
Hi,

On 2021-11-18 13:39:04 -0500, Tom Lane wrote:
> After studying configure's list more closely, that doesn't seem like
> a great plan either.  There's a lot of idiosyncrasy in the tests,
> such as things that only apply to C or to C++.

Yea. It seems doable, but not really worth it for now.


> More, I think (though this ought to be documented in a comment) that
> the policy is to not bother turning on extra -W options in the bitcode
> switches, on the grounds that warning once in the main build is enough.
> I follow that idea --- but what we missed is that we still need to
> turn *off* the warnings we're actively disabling.  I shall go do that,
> if no objections.

Thanks for doing that, that does sounds like a good way, at least for now.


On 2021-11-18 13:39:04 -0500, Tom Lane wrote:
> That sounds fairly horrid, but as long as you are using an accache file it's
> not really going to cost that much.

> (BTW, does meson have any comparable optimization?
> If it doesn't, I bet that is going to be a problem.)

Yes - imo in a nicer, more reliable way. It caches most test results, but with
the complete input, including the commandline (i.e. compiler flags) as the
cache key. So no more errors about compile flags changing...

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Time to drop plpython2?
Next
From: Andres Freund
Date:
Subject: Re: Mixing CC and a different CLANG seems like a bad idea