[GRASS5] nviz compile in grass51: source of problem

GRASS GRASS developer
1

Hi,

I currently updated the Postgres files in nviz src catalog:

For GRASS 5.0:
Changed:
----------
Gmakefile
postgr_query_orig.c
postgr_query.c
(the two are the same if pg support enabled)
getCat.c

Removed:
----------
buildInfxQry.c
runInfxQry.c
infx.h

Added:
----------

buildPg.c
runPg.c
pg.h

For GRASS51:

Changed:
----------
nviz/doconfigure
nviz/src/getCat.c

Also to handle the problem in compiling under grass51 which in my view comes
out from fact that sources must compile under both GRASSes (i.e. 5.0 and 5.1) whilst
config.in files in source trees differ in the way Postgres is defined:

/* define if postgres exists */
#undef HAVE_POSTGRES
#undef HAVE_POSTGRES_H

- in grass51

and
/* define if postgres.h exists */
#undef HAVE_POSTGRES_H

/* define if postgres_fe.h exists */
#undef HAVE_POSTGRES_FE_H

So the check in nviz/src/runPg.c now looks like:

#if defined(HAVE_POSTGRES) || defined(HAVE_POSTGRES_H) || defined(HAVE_POSTGRES_FE_H)

So that is how it is supposed to compile under both trees. I don't know if it's ok as
doconfigure in turn defines if Postgres should be used from $(PQLIB). Optimal,
they all should check one value rather than three or four different ones.

I agree with Radim that support in nviz should be extended through dbmi driver,
but so far we don't have pg/mysql dbmi driver in grass5.0, so the source
should compile under both trees with difficulty if still directly hooked
to postgres and with access to odbc and dbf through dbmi.
If we split the source of nviz (which I think we shouldn't) we then get maintaining
both trees.

--alex

2

Alex Shevlakov wrote:

Also to handle the problem in compiling under grass51 which in my view comes
out from fact that sources must compile under both GRASSes (i.e. 5.0 and 5.1) whilst
config.in files in source trees differ in the way Postgres is defined:

/* define if postgres exists */
#undef HAVE_POSTGRES
#undef HAVE_POSTGRES_H

- in grass51

and
/* define if postgres.h exists */
#undef HAVE_POSTGRES_H

/* define if postgres_fe.h exists */
#undef HAVE_POSTGRES_FE_H

So the check in nviz/src/runPg.c now looks like:

#if defined(HAVE_POSTGRES) || defined(HAVE_POSTGRES_H) || defined(HAVE_POSTGRES_FE_H)

I suspect that it should probably just be

  #if defined(HAVE_POSTGRES)

Alternatively, add:

  #undef HAVE_LIBPQ_FE_H

to config.h.in and use that instead of HAVE_POSTGRES.

So that is how it is supposed to compile under both trees. I don't know if it's ok as
doconfigure in turn defines if Postgres should be used from $(PQLIB). Optimal,
they all should check one value rather than three or four different ones.

Both HAVE_POSTGRES_H and HAVE_POSTGRES_FE_H should be redundant if
g.column.pg no longer relies upon those headers for VARHDRSZ. In which
case, the checks should probably be removed from configure[.in], as
they require the user to provide the path to the "internal" headers.
Assuming that the user even has those headers; it wouldn't be
unreasonable for vendors to put them in a separate package from
libpq-fe.h, given that they aren't needed by clients.

HAVE_POSTGRES is explicitly defined by configure (5.1 only) if
PostgreSQL support is enabled. Using HAVE_LIBPQ_FE_H might be
preferable, as it is set automatically by the header check.

If you need a symbol for use in a Makefile, add a line for
USE_POSTGRES to Platform.make.in. For each --with-* switch, a
corresponding USE_* configure variable is defined to "1" if the option
is enabled and to "" (empty) otherwise.

However, the real hack is the "doconfigure" script. It would be
preferable to just conditionalise the body of runPg.c upon
HAVE_POSTGRES (I've already done this part for 5.0), and merge
query_postgr_{orig,dummy}.c (which is trivial; query_postgr_dummy.c is
just a stub).

Similarly, panel_query_{orig,pg}.tcl should be merged. While this step
would constitute most of the work involved in removing the doconfigure
script, in some respects the situation for Tcl code is simpler than
for C, as undefined symbols don't matter if you don't actually execute
the corresponding code.

Alternatively, you could just have panel_query.tcl do e.g.:

  if {[have_postgres]} {
    source panel_query_pg.tcl
  } {
    source panel_query_orig.tcl
  }

This would require that the nvwish binary provides a Tcl function
to indicate whether it was built with PostgreSQL support.

--
Glynn Clements <glynn.clements@virgin.net>

3

--- Glynn Clements <glynn.clements@virgin.net> wrote:

Alex Shevlakov wrote:

> /* define if postgres exists */
> #undef HAVE_POSTGRES
> #undef HAVE_POSTGRES_H
>
> - in grass51
>
> and
> /* define if postgres.h exists */
> #undef HAVE_POSTGRES_H
>
> /* define if postgres_fe.h exists */
> #undef HAVE_POSTGRES_FE_H
>
> So the check in nviz/src/runPg.c now looks like:
>
> #if defined(HAVE_POSTGRES) ||
defined(HAVE_POSTGRES_H) ||
defined(HAVE_POSTGRES_FE_H)

I suspect that it should probably just be

  #if defined(HAVE_POSTGRES)

Like this it will not compile under 'grass' tree if
config.in.h was left unchanged. HAVE_POSTGRES is
not in it now.

Alternatively, add:

  #undef HAVE_LIBPQ_FE_H

to config.h.in and use that instead of
HAVE_POSTGRES.

I mean a kind problem is lack of synchronicity in two
trees
to this point.

Both HAVE_POSTGRES_H and HAVE_POSTGRES_FE_H should
be redundant if
g.column.pg no longer relies upon those headers for
VARHDRSZ.

This value I literally placed in g.column.pg.
So we can remove those macros from 'grass' config.in.h
and following checks from configure.[in]

In which

case, the checks should probably be removed from
configure[.in], as
they require the user to provide the path to the
"internal" headers.

This is the case after I removed the internal header
reference from g.column.pg.

HAVE_POSTGRES is explicitly defined by configure
(5.1 only) if
PostgreSQL support is enabled. Using HAVE_LIBPQ_FE_H
might be
preferable, as it is set automatically by the header
check.

If you need a symbol for use in a Makefile, add a
line for
USE_POSTGRES to Platform.make.in. For each --with-*
switch, a
corresponding USE_* configure variable is defined to
"1" if the option
is enabled and to "" (empty) otherwise.

However, the real hack is the "doconfigure" script.
It would be
preferable to just conditionalise the body of
runPg.c upon
HAVE_POSTGRES (I've already done this part for 5.0),
and merge
query_postgr_{orig,dummy}.c (which is trivial;
query_postgr_dummy.c is
just a stub).

Similarly, panel_query_{orig,pg}.tcl should be
merged. While this step
would constitute most of the work involved in
removing the doconfigure
script, in some respects the situation for Tcl code
is simpler than
for C, as undefined symbols don't matter if you
don't actually execute
the corresponding code.

Alternatively, you could just have panel_query.tcl
do e.g.:

  if {[have_postgres]} {
    source panel_query_pg.tcl
  } {
    source panel_query_orig.tcl
  }

This would require that the nvwish binary provides a
Tcl function
to indicate whether it was built with PostgreSQL
support.

I think 'definetely, yes' as soon as configure is
uniform.

--alex

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

4

On Saturday 30 November 2002 03:29 pm, you wrote:

I agree with Radim that support in nviz should be extended through dbmi
driver, but so far we don't have pg/mysql dbmi driver in grass5.0, so the
source should compile under both trees with difficulty if still directly
hooked to postgres and with access to odbc and dbf through dbmi.
If we split the source of nviz (which I think we shouldn't) we then get
maintaining both trees.

NVIZ in 5.0 and 5.1 differ anyway: 3D vectors, sites.
To get pg driver in 5.0 should not be more work than to copy it from 5.1.
NVIZ based on DBMI would be end of problems with distribution of 2 versions
of binaries, but I don't think that 5.0.1(2) is good for such new feature.

Radim

5

--- Glynn Clements <glynn.clements@virgin.net> wrote:

Alex Shevlakov wrote:

> Also to handle the problem in compiling under
grass51 which in my view comes
> out from fact that sources must compile under both
GRASSes (i.e. 5.0 and 5.1) whilst
> config.in files in source trees differ in the way
Postgres is defined:
>
> /* define if postgres exists */
> #undef HAVE_POSTGRES
> #undef HAVE_POSTGRES_H
>
> - in grass51
>
> and
> /* define if postgres.h exists */
> #undef HAVE_POSTGRES_H
>
> /* define if postgres_fe.h exists */
> #undef HAVE_POSTGRES_FE_H
>
> So the check in nviz/src/runPg.c now looks like:
>
> #if defined(HAVE_POSTGRES) ||
defined(HAVE_POSTGRES_H) ||
defined(HAVE_POSTGRES_FE_H)

I suspect that it should probably just be

  #if defined(HAVE_POSTGRES)

Alternatively, add:

  #undef HAVE_LIBPQ_FE_H

to config.h.in and use that instead of
HAVE_POSTGRES.

I just added HAVE_LIBPQ_FE_H and removed POSTGRES_H
and POSTGRES_FE_H from all code.

HAVE_POSTGRES is explicitly defined by configure
(5.1 only) if
PostgreSQL support is enabled. Using HAVE_LIBPQ_FE_H
might be
preferable, as it is set automatically by the header
check.

Yes I agree to that.

If you need a symbol for use in a Makefile, add a
line for
USE_POSTGRES to Platform.make.in. For each --with-*
switch, a
corresponding USE_* configure variable is defined to
"1" if the option
is enabled and to "" (empty) otherwise.

This is what I was thinking of (not done)

However, the real hack is the "doconfigure" script.
It would be
preferable to just conditionalise the body of
runPg.c upon
HAVE_POSTGRES (I've already done this part for 5.0),
and merge
query_postgr_{orig,dummy}.c (which is trivial;
query_postgr_dummy.c is
just a stub).

I just merged the two into query_postgr.c and removed
the stubs.

Similarly, panel_query_{orig,pg}.tcl should be
merged. While this step
would constitute most of the work involved in
removing the doconfigure
script, in some respects the situation for Tcl code
is simpler than
for C, as undefined symbols don't matter if you
don't actually execute
the corresponding code.

Alternatively, you could just have panel_query.tcl
do e.g.:

  if {[have_postgres]} {
    source panel_query_pg.tcl
  } {
    source panel_query_orig.tcl
  }

This would require that the nvwish binary provides a
Tcl function
to indicate whether it was built with PostgreSQL
support.

I left this part of doconfigure unchanged for now.

--alex

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com