Hi,
On Mon, 2018-04-16 at 09:24 +0200, Christoph Berg wrote:
> Fwiw, setting MAKELEVEL=0 worked. Thanks!
Great, it solved my problem as well! Thanks Tom.
Regards,
--
Devrim Gündüz
EnterpriseDB: https://www.enterprisedb.com
PostgreSQL Consultant, Red Hat Certified Engineer
Twitter: @DevrimGundu
Re: To Tom Lane 2018-04-12 <20180412202717.ga32...@msg.df7cb.de>
> > ... or then again, maybe I do. Is it possible that your build
> > recipe involves invoking our makefiles from an outer "make" run?
> > If so, maybe you need to explicitly set MAKELEVEL=0 when invoking
> > our build, to keep it fr
Hi Tom,
On Thu, 2018-04-12 at 14:36 -0400, Tom Lane wrote:
> I don't have F27 at hand, but I tried F26 and F28, and I can't reproduce
> on either one.
I uploaded the SRPM for you:
https://gunduz.org/temp/postgresql11-11.0-20180415_1PGDG.f27.src.rpm
I built this SRPM using daily snapshot at:
h
Re: Tom Lane 2018-04-12 <10354.1523558...@sss.pgh.pa.us>
> ... or then again, maybe I do. Is it possible that your build
> recipe involves invoking our makefiles from an outer "make" run?
> If so, maybe you need to explicitly set MAKELEVEL=0 when invoking
> our build, to keep it from thinking it i
On 2018-04-12 11:22:45 -0700, Jacob Champion wrote:
> On Thu, Apr 12, 2018 at 11:00 AM, Tom Lane wrote:
> > Andrew Gierth writes:
> >> Is it worth exploring the idea of changing to a non-recursive style of
> >> makefile?
> >
> > Not post-feature-freeze, for sure. Whether it's worth the work as a
> "Alvaro" == Alvaro Herrera writes:
Alvaro> I'm altogether ignorant on how might we use it for the headers
Alvaro> problem, mind. I only tried to tackle the main executable.
Solving the headers problem would seem to require making things
non-recursive at the topmost level rather than tryi
Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes:
> ... still same error. Easy to reproduce on F-27 box.
I don't have F27 at hand, but I tried F26 and F28, and I can't reproduce
on either one. I tried various combinations of python2 versus python3,
in-tree build versus VPATH from bare checkout versus
On Thu, Apr 12, 2018 at 11:00 AM, Tom Lane wrote:
> Andrew Gierth writes:
>> Is it worth exploring the idea of changing to a non-recursive style of
>> makefile?
>
> Not post-feature-freeze, for sure. Whether it's worth the work as a
> long-term project, I dunno.
I've been taking a look at this
Andrew Gierth wrote:
> > "Tom" == Tom Lane writes:
>
> Tom> I'm beginning to get dissatisfied with this approach of expecting
> Tom> the topmost Make run to do the generated-headers work
>
> Is it worth exploring the idea of changing to a non-recursive style of
> makefile?
I looked onto t
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> I'm beginning to get dissatisfied with this approach of expecting
> Tom> the topmost Make run to do the generated-headers work
> Is it worth exploring the idea of changing to a non-recursive style of
> makefile?
Not post-feature-freeze,
> "Tom" == Tom Lane writes:
Tom> I'm beginning to get dissatisfied with this approach of expecting
Tom> the topmost Make run to do the generated-headers work
Is it worth exploring the idea of changing to a non-recursive style of
makefile?
--
Andrew (irc:RhodiumToad)
Hi Tom,
On Wed, 2018-04-11 at 10:16 -0400, Tom Lane wrote:
> You sure you're on 31f1f0bb4fd642643994d35c35ecb5b929711a99 or later?
To make sure, I am using latest git snapshot:
https://download.postgresql.org/pub/snapshot/dev/postgresql-snapshot.tar.bz2
and still same error. Easy to reproduce
Michael Paquier writes:
> But this does not work:
> ./configure blah
> cd src/pl/plpython/
> make -j 4 check
Hm. That shows yet another parallel-safety hazard, which can be resolved
like this:
diff --git a/src/pl/plpython/Makefile b/src/pl/plpython/Makefile
index 653fe64..c17015b 100644
--- a/s
Christoph Berg writes:
> Most of these work for me as well. The actual incantation via
> debian/rules fails, but I couldn't really narrow down what the
> difference is. Manually invoking the debian/rules targets:
For a moment I thought that this might be the critical difference:
> preparing build
Re: Michael Paquier 2018-04-12 <20180411235843.gg32...@paquier.xyz>
> > You sure you're on 31f1f0bb4fd642643994d35c35ecb5b929711a99 or later?
> > Which gmake version is this?
GNU Make 4.2.1
> For what it's worth, all those combinations work for me when on
> d1e90792:
> ./configure blah
> cd src/p
On Wed, Apr 11, 2018 at 10:16:24AM -0400, Tom Lane wrote:
> That works for me:
>
> $ git clean -dfx
> $ ./configure ... --with-python and other stuff ...
> $ cd src/pl/plpython
> $ make all
> make -C ../../../src/backend generated-headers
> make[1]: Entering directory `/home/postgres/pgsql/src/bac
Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes:
> On Wed, 2018-04-11 at 09:38 -0400, Tom Lane wrote:
>> *What* still doesn't work on current HEAD? I don't know what commands
>> you are running to get this.
> I think my build and Christoph's builds fail because of the same reason again
> (the same as
Hi,
On Wed, 2018-04-11 at 09:38 -0400, Tom Lane wrote:
> *What* still doesn't work on current HEAD? I don't know what commands
> you are running to get this.
I think my build and Christoph's builds fail because of the same reason again
(the same as yesterday):
=
Christoph Berg writes:
> It still doesn't work on current HEAD:
*What* still doesn't work on current HEAD? I don't know what commands
you are running to get this.
regards, tom lane
Re: Tom Lane 2018-04-10 <24426.1523387...@sss.pgh.pa.us>
> The short-term solution seems to be to put that back, but that's sort
> of annoying because it means this isn't a bulletproof solution. It
> will only work for builds started in one of the directories that we
> take the trouble to put this
Alvaro Herrera writes:
> Tom Lane wrote:
>> $(OBJS): | submake-generated-headers
>> but I took it out thinking it was no longer needed.
>>
>> The short-term solution seems to be to put that back, but that's sort
>> of annoying because it means this isn't a bulletproof solution.
> Isn't it possib
Tom Lane wrote:
> $(OBJS): | submake-generated-headers
>
> but I took it out thinking it was no longer needed.
>
> The short-term solution seems to be to put that back, but that's sort
> of annoying because it means this isn't a bulletproof solution. It
> will only work for builds started in on
I wrote:
> Hm ... you're cd'ing into src/pl/plpython and issuing "make all"?
> That works for me.
> ... or, wait ... with -j it doesn't. That's strange, will look.
So after a bit of digging, it seems that the locution
all: submake-generated-headers
doesn't result in ensuring that submake-genera
Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes:
> On Tue, 2018-04-10 at 10:01 -0400, Tom Lane wrote:
>> You could replace it with submake-generated-headers, since that's more
>> general, but in principle you shouldn't need anything because that
>> target is invoked automatically as of yesterday. What'
Hi,
On Tue, 2018-04-10 at 10:01 -0400, Tom Lane wrote:
> You could replace it with submake-generated-headers, since that's more
> general, but in principle you shouldn't need anything because that
> target is invoked automatically as of yesterday. What's the larger
> context here --- why do you
Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes:
> I used to run
> "
> cd src/backend
> make submake-errcodes
> "
> in the RPM spec file, but looks like it was removed recently. Is that replaced
> with something else, or removed completely?
You could replace it with s
Re: Devrim Gündüz 2018-04-10 <1523353963.8169.26.ca...@gunduz.org>
> I used to run
>
> "
> cd src/backend
> make submake-errcodes
> "
>
> in the RPM spec file, but looks like it was removed recently. Is that replaced
> with something else
Hi,
I used to run
"
cd src/backend
make submake-errcodes
"
in the RPM spec file, but looks like it was removed recently. Is that replaced
with something else, or removed completely?
Regards,
--
Devrim Gündüz
EnterpriseDB: https://www.enterprisedb.com
PostgreSQL Consultant, Red Hat
28 matches
Mail list logo
