Re: [PATCHES] Another VPATH patch for ecpg

Hi,

I just detected another problem with building ecpg in a VPATH
environment. This patch fixes it for me.

This is needed because ecpg_config.h ends up in the build dir rather
than the source dir.

Thanks,

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

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/

Alvaro Herrera <alvherre(at)commandprompt(dot)com> 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.

regards, tom lane

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> 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.
>
>
>

I will set one up tomorrow.

cheers

andrew

Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>> Alvaro Herrera <alvherre(at)commandprompt(dot)com> 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.
>>
>>
>>
>
> I will set one up tomorrow.
>

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.

cheers

andrew

Andrew Dunstan wrote:
> Andrew Dunstan wrote:
> >
> >
> >Tom Lane wrote:
> >>Alvaro Herrera <alvherre(at)commandprompt(dot)com> 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.
> >>
> >>
> >>
> >
> >I will set one up tomorrow.
> >
>
> 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.

That's because this is a different problem. The patch I provided was to
fix a problem in the regression tests -- the problem you are seeing is
on the
`/home/andrew/bf/root/HEAD/pgsql.3694/src/interfaces/ecpg/pgtypeslib'
directory.

I'll take a look.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Andrew Dunstan <andrew(at)dunslane(dot)net> 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 around, I'm down to diffs like these in the
preprocessor output files:

116c116
< #line 36 "show.pgc"
---
> #line 36 "/home/tgl/pgsql/src/interfaces/ecpg/test/sql/show.pgc"
119c119
< #line 36 "show.pgc"
---
> #line 36 "/home/tgl/pgsql/src/interfaces/ecpg/test/sql/show.pgc"
122c122
< #line 36 "show.pgc"
---
> #line 36 "/home/tgl/pgsql/src/interfaces/ecpg/test/sql/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.

regards, tom lane

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 lines before diffing the files? This is already
done for different default port settings in order to keep output files in
sync.

I append a small (untested) patch against pg_regress.sh.

Unfortunately, lines like this one in a non-VPATH build:

#line 1 "./../../include/sql3types.h"

would get stripped to `#line 1 "sql3types.h"' as well but I think this is
acceptable.

Joachim

--
Joachim Wieland joe(at)mcknight(dot)de
GPG key available

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 for me and it's reaonable to have the paths
shortened IMO.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes(at)jabber(dot)org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

Michael Meskes <meskes(at)postgresql(dot)org> 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. Let's see how it goes.

I don't see that patch actually committed, and HEAD still fails the ecpg
tests in a VPATH build.

regards, tom lane

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
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes(at)jabber(dot)org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

Michael Meskes <meskes(at)postgresql(dot)org> 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.

regards, tom lane

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.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes(at)jabber(dot)org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

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 wrong. I
> changed the file, then ran an cvs update and then committed.

Umm, just looking at the CVS commit logs gives this odd result:

http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/compat_informix-dec_test.c.diff?r1=1.4&r2=1.5
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/compat_informix-dec_test.c.diff?r1=1.5&r2=1.6
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/expected/compat_informix-dec_test.c.diff?r1=1.6&r2=1.7

(the diffs between revisions 1.4, 1.5, 1.6 and 1.7 for the
compat_informix-dec_test.c.diff file).

It changed and changed back again, very odd...

Hope this helps,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.