[GRASS5] nviz compile in grass51: source of problem

[Alex Shevlakov]

--- Glynn Clements <glynn.clements at 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