On Tue, Aug 29, 2006 at 04:29:28PM +0200, Michael Meskes wrote:
> On Tue, Aug 29, 2006 at 09:56:58AM -0400, Tom Lane wrote:
> > Wow, I've never had CVS miss a commit (at least not through *its* error
> > ;-)). Better look into that.
>
> No, it's probably my fault, but I fail to see what I made wr
On Tue, Aug 29, 2006 at 09:56:58AM -0400, Tom Lane wrote:
> Wow, I've never had CVS miss a commit (at least not through *its* error
> ;-)). Better look into that.
No, it's probably my fault, but I fail to see what I made wrong. I
changed the file, then ran an cvs update and then committed.
Micha
Michael Meskes <[EMAIL PROTECTED]> writes:
> Argh! The second time my system doesn't commit all changes. I wonder
> what's going wrong.
Wow, I've never had CVS miss a commit (at least not through *its* error
;-)). Better look into that.
> I tried again. Do you see it now?
Yeah, looks good now.
On Tue, Aug 29, 2006 at 08:55:10AM -0400, Tom Lane wrote:
> I don't see that patch actually committed, and HEAD still fails the ecpg
> tests in a VPATH build.
Argh! The second time my system doesn't commit all changes. I wonder
what's going wrong. I tried again. Do you see it now?
Michael
--
Mi
Michael Meskes <[EMAIL PROTECTED]> writes:
> On Mon, Aug 28, 2006 at 11:03:25PM +0200, Joachim Wieland wrote:
>> What about changing those lines before diffing the files? This is already
>> done for different default port settings in order to keep output files in
>> sync.
> I applied that patch. L
On Mon, Aug 28, 2006 at 11:03:25PM +0200, Joachim Wieland wrote:
> What about changing those lines before diffing the files? This is already
> done for different default port settings in order to keep output files in
> sync.
I applied that patch. Let's see how it goes.
Needless to say it worked f
On Mon, Aug 28, 2006 at 12:16:40PM -0400, Tom Lane wrote:
> 122c122
> < #line 36 "show.pgc"
> AFAICS there is no very good way to deal with this. I'd suggest
> providing a way to suppress #line output from the ecpg preprocessor,
> but perhaps there is another answer.
What about changing those li
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Done. New machine is 'bustard'. But I couldn't get Alvaro's patch nor
> Peter's suggestion to work :-( Maybe someone with more vpath-fu than me
> can fix it.
I got it to build fairly easily, but the ecpg regression tests are a mess.
After some fooling
Andrew Dunstan wrote:
> Andrew Dunstan wrote:
> >
> >
> >Tom Lane wrote:
> >>Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >>
> >>>I just detected another problem with building ecpg in a VPATH
> >>>environment. This patch fixes it for me.
> >>>
> >>
> >>Can't we get some of the buildfarm machi
Andrew Dunstan wrote:
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
I just detected another problem with building ecpg in a VPATH
environment. This patch fixes it for me.
Can't we get some of the buildfarm machines exercising VPATH?
This kinda stuff really ought to be f
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
I just detected another problem with building ecpg in a VPATH
environment. This patch fixes it for me.
Can't we get some of the buildfarm machines exercising VPATH?
This kinda stuff really ought to be found immediately.
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I just detected another problem with building ecpg in a VPATH
> environment. This patch fixes it for me.
Can't we get some of the buildfarm machines exercising VPATH?
This kinda stuff really ought to be found immediately.
regar
Alvaro Herrera wrote:
> I just detected another problem with building ecpg in a VPATH
> environment. This patch fixes it for me.
I think you will find that $(top_builddir)/$(subdir) is equivalent
to "."
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(e
13 matches
Mail list logo
