Re: Michael Paquier 2019-02-03 <20190203090737.ga18...@paquier.xyz>
> >> Attached is a patch doing that. Thoughts?
> >
> > WFM.
>
> Thanks, pushed.
Thanks. It makes much more sense that way round.
Christoph
--
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080,
On Thu, Jan 31, 2019 at 10:51:11PM -0500, Tom Lane wrote:
> Michael Paquier writes:
>> Attached is a patch doing that. Thoughts?
>
> WFM.
Thanks, pushed.
--
Michael
signature.asc
Description: PGP signature
Michael Paquier writes:
> Attached is a patch doing that. Thoughts?
WFM.
regards, tom lane
On Thu, Jan 31, 2019 at 11:19:11AM +0900, Michael Paquier wrote:
> Ah yes, good point about CFLAGS and LDFLAGS. It would be better to
> add a comment about that and document the difference, aka "prepend" or
> "append" the flag values.
>
> CXXFLAGS applies to compiler options like -g -O2 which
On Wed, Jan 30, 2019 at 08:18:31PM -0500, Tom Lane wrote:
> This looks a bit copy-and-paste-y to me, in particular no thought
> has been taken for the order of flags. We found in configure that
> it's better to add user-specified CFLAGS at the *end*, even though
> injecting user-specified
Michael Paquier writes:
> On Wed, Jan 30, 2019 at 02:41:01PM +0100, Christoph Berg wrote:
>> Do we still want some CXXOPT flag for the server build? I can write a
>> patch, but someone else would need to do the bikeshedding how to name
>> it, and which of the existing knobs would set CXXFLAGS
On Wed, Jan 30, 2019 at 02:41:01PM +0100, Christoph Berg wrote:
> Do we still want some CXXOPT flag for the server build? I can write a
> patch, but someone else would need to do the bikeshedding how to name
> it, and which of the existing knobs would set CXXFLAGS along. I don't
> think I need
Re: Andres Freund 2019-01-30 <20190130015127.hciz36lpmu7pr...@alap3.anarazel.de>
> I'm confused - that doesn't allow to inject flags to all in-core built
> files? So how does that fix your problem fully? Say
> e.g. llvmjit_inline.cpp won't get the flag, and thus not be
> reproducible?
The
Hi,
On 2019-01-29 16:18:46 +0100, Christoph Berg wrote:
> Re: Michael Paquier 2019-01-23 <20190123004722.ge3...@paquier.xyz>
> > >> Largely because I think it's an independent patch from the CXXOPT need
> > >> from Christopher / Debian packaging. It's a larger patch, that needs
> > >> more docs
On Tue, Jan 29, 2019 at 04:18:46PM +0100, Christoph Berg wrote:
> Re backpatching, I would at least need them in PG11 because that's
> what is going to be released with Debian buster. An official backpatch
> to all supported versions would be nice, but I could also sneak in
> that change into the
Re: Michael Paquier 2019-01-23 <20190123004722.ge3...@paquier.xyz>
> >> Largely because I think it's an independent patch from the CXXOPT need
> >> from Christopher / Debian packaging. It's a larger patch, that needs
> >> more docs etc. If whoever applies that wants to backpatch it - I'm not
>
On Tue, Jan 22, 2019 at 06:11:23PM -0300, Alvaro Herrera wrote:
> On 2019-Jan-22, Andres Freund wrote:
>> Largely because I think it's an independent patch from the CXXOPT need
>> from Christopher / Debian packaging. It's a larger patch, that needs
>> more docs etc. If whoever applies that wants
Hello
On 2019-Jan-22, Andres Freund wrote:
> On 2019-01-22 17:10:58 -0300, Alvaro Herrera wrote:
> > I don't understand why you don't want to backpatch the PGXS bits.
>
> Largely because I think it's an independent patch from the CXXOPT need
> from Christopher / Debian packaging. It's a
Hi,
On 2019-01-22 17:10:58 -0300, Alvaro Herrera wrote:
> On 2019-Jan-22, Andres Freund wrote:
>
> > I think its plain wrong to add COPT to CXXFLAGS. Re PROFILE I'm on the
> > fence. I personally think the pgxs stuff is a bit separate, and I'm
> > doubtful we ought to backpatch that. I'm
On 2019-Jan-22, Andres Freund wrote:
> I think its plain wrong to add COPT to CXXFLAGS. Re PROFILE I'm on the
> fence. I personally think the pgxs stuff is a bit separate, and I'm
> doubtful we ought to backpatch that. I'm basically planning to apply
>
On 2019-01-22 15:26:21 +0900, Michael Paquier wrote:
> On Thu, Jan 17, 2019 at 02:55:39PM +0900, Michael Paquier wrote:
> > Personally I see pgxs as something completely different than what COPT
> > and PROFILE are as we are talking about two different facilities: one
> > which is part of the core
On Thu, Jan 17, 2019 at 02:55:39PM +0900, Michael Paquier wrote:
> Personally I see pgxs as something completely different than what COPT
> and PROFILE are as we are talking about two different facilities: one
> which is part of the core installation, and the other which can be
> used for
On Tue, Jan 08, 2019 at 09:09:56AM +0100, Christoph Berg wrote:
> Re: Andres Freund 2019-01-08
> <20190108011837.n4mx7dadvojv2...@alap3.anarazel.de>
>>> Here's another revision that doesn't add an extra CXXOPT variable but
>>> just extends CXXFLAGS whenever COPT or PROFILE are set, which seems
Re: Andres Freund 2019-01-08 <20190108011837.n4mx7dadvojv2...@alap3.anarazel.de>
> > Here's another revision that doesn't add an extra CXXOPT variable but
> > just extends CXXFLAGS whenever COPT or PROFILE are set, which seems
> > more usable.
>
> Why does that seem more usable? How's that
Hi,
On 2019-01-07 10:32:20 +0100, Christoph Berg wrote:
> Re: To Michael Paquier 2019-01-07 <20190107091734.ga1...@msg.credativ.de>
> > Updated patch attached.
>
> Here's another revision that doesn't add an extra CXXOPT variable but
> just extends CXXFLAGS whenever COPT or PROFILE are set,
On Mon, Jan 07, 2019 at 10:32:20AM +0100, Christoph Berg wrote:
> Here's another revision that doesn't add an extra CXXOPT variable but
> just extends CXXFLAGS whenever COPT or PROFILE are set, which seems
> more usable.
>
> It also updates the documentation.
The documentation is not fully
Re: To Michael Paquier 2019-01-07 <20190107091734.ga1...@msg.credativ.de>
> Updated patch attached.
Here's another revision that doesn't add an extra CXXOPT variable but
just extends CXXFLAGS whenever COPT or PROFILE are set, which seems
more usable.
It also updates the documentation.
Christoph
Re: Michael Paquier 2019-01-04 <20190104133305.gg2...@paquier.xyz>
> On Fri, Jan 04, 2019 at 11:41:15AM +0100, Peter Eisentraut wrote:
> > Note that pgxs supports PG_CPPFLAGS for adding custom pieces to CPPFLAGS
> > in a safe way. Maybe we should add an equivalent for CFLAGS? It's just
> > that
On Fri, Jan 04, 2019 at 11:41:15AM +0100, Peter Eisentraut wrote:
> Note that pgxs supports PG_CPPFLAGS for adding custom pieces to CPPFLAGS
> in a safe way. Maybe we should add an equivalent for CFLAGS? It's just
> that it hasn't been needed so far.
+1. Wouldn't it make sense to also have
On 21/11/2018 14:28, Christoph Berg wrote:
> The context here is that we want to use the *FLAGS from pg_config for
> compiling PG extension packages, but add additional *FLAGS from the
> extension build environment. Merging the pg_config CFLAGS with the
> environment CFLAGS seemed
(Sorry for the delayed response here.)
Re: Andres Freund 2018-11-13 <20181113223330.2ql7tg33hhh6h...@alap3.anarazel.de>
> > >> While working on making extension modules built reproducibly, I
> > >> noticed that extra flags passed via COPT (notably -ffile-prefix-map)
> > >> do not get added to
Hi,
On 2018-11-13 17:27:17 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-11-13 11:40:05 +0100, Christoph Berg wrote:
> >> While working on making extension modules built reproducibly, I
> >> noticed that extra flags passed via COPT (notably -ffile-prefix-map)
> >> do not get added
Andres Freund writes:
> On 2018-11-13 11:40:05 +0100, Christoph Berg wrote:
>> While working on making extension modules built reproducibly, I
>> noticed that extra flags passed via COPT (notably -ffile-prefix-map)
>> do not get added to CXXFLAGS.
> PROFILE I can see, but COPT I'm less sure. The
Hi,
On 2018-11-13 11:40:05 +0100, Christoph Berg wrote:
> While working on making extension modules built reproducibly, I
> noticed that extra flags passed via COPT (notably -ffile-prefix-map)
> do not get added to CXXFLAGS.
PROFILE I can see, but COPT I'm less sure. The name suggests it's about
29 matches
Mail list logo
