Обсуждение: Re: [COMMITTERS] pgsql/ /aclocal.m4 /build.xml /configure /conf ...
Peter Mount writes:
> What it does is add a new option to configure: --with-java
>
> This option tells configure to look for ant (our build tool of choice) and
> if found, it then compiles both the JDBC driver and the new tools as part
> of the normal make.
Nice!
> Also, when the postgresql install is done, all the .jar files are also
> installed into the ${PGLIB}/java directory (thought best to keep then separate)
Since the Java files are platform independent, the GNU file system
standard would prefer Java files to be installed under $(prefix)/share/.
If we stick with lib/, we should probably be creating a lib/postgresql
subdirectory, like we do in the other subtrees.
Some other thoughts:
Shouldn't the interfaces/jdbc/Makfile be using interfaces/jdbc/build.xml
rather than the one on top? Is the one on top still needed?
In PGAC_PROG_ANT, it might be worth running the found program to see if it
actually works. (On a vanilla Linux installation with Kaffe it probably
won't unless the user manually configured the class path.)
If I find some time I'm going to look if I can implement uninstall and
building outside the source tree for the jdbc subtree.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Quoting Peter Eisentraut <peter_e@gmx.net>:
> Peter Mount writes:
>
> > What it does is add a new option to configure: --with-java
> >
> > This option tells configure to look for ant (our build tool of
> choice) and
> > if found, it then compiles both the JDBC driver and the new tools as
> part
> > of the normal make.
>
> Nice!
>
> > Also, when the postgresql install is done, all the .jar files are
> also
> > installed into the ${PGLIB}/java directory (thought best to keep then
> separate)
>
> Since the Java files are platform independent, the GNU file system
> standard would prefer Java files to be installed under
> $(prefix)/share/.
That is true, but which vars (in configure/Makefile.global etc) define this?
Also what about the platforms that don't use the GNU FSS?
Anyhow, it's easy as it's defined on one line
> If we stick with lib/, we should probably be creating a lib/postgresql
> subdirectory, like we do in the other subtrees.
Ah, you are getting confused. The java directory is beneath the one install
makes for postgresql already, not along side, so for example (based on my
laptop NT/Cygwin):
/usr/local/pgsql/lib where PGLIB is
/usr/local/pgsql/lib/java where the .jars are put.
> Some other thoughts:
>
> Shouldn't the interfaces/jdbc/Makfile be using
> interfaces/jdbc/build.xml
> rather than the one on top? Is the one on top still needed?
The top one is used to refer to both src/interfaces/jdbc/build.xml and
contrib/retep/build.xml, that way running ant at the bottom builds the lot.
Originally I was going to get ANT to run from there directly, but found I
couldn't easily add it into the rest of the build sequence easily, hence why
there's the reference back to the base xml file from interfaces/jdbc.
Perhaps later we can remove that hack and get it working from the base one.
> In PGAC_PROG_ANT, it might be worth running the found program to see if
> it
> actually works. (On a vanilla Linux installation with Kaffe it
> probably
> won't unless the user manually configured the class path.)
May be for 7.1.1, add a "test" target to the base build.xml file. If it runs,
then the test passes.
I'm trying to concentrate on many bug fixes (so far none needed - touch wood ;-
) ) getting the tutorials done and porting the tools over (the contrib stuff)
ready for 7.1.
> If I find some time I'm going to look if I can implement uninstall and
> building outside the source tree for the jdbc subtree.
The one thing I didn't put in there is getting the version numbers out of
Makefile.global. It's just a couple of -D parameters to add to
interfaces/jdbc/Makefile. build.xml and Driver.java.in already support them.
Peter
--
Peter Mount peter@retep.org.uk
PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/
RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/
Peter T Mount writes:
> > Since the Java files are platform independent, the GNU file system
> > standard would prefer Java files to be installed under
> > $(prefix)/share/.
>
> That is true, but which vars (in configure/Makefile.global etc) define this?
$(datadir)
> Also what about the platforms that don't use the GNU FSS?
They use configure options to override the locations. In practice, no
system uses the GNU FSS (except the HURD maybe), but the idea is that all
locations are configurable in some sort of orthogonal way.
> > If we stick with lib/, we should probably be creating a lib/postgresql
> > subdirectory, like we do in the other subtrees.
>
> Ah, you are getting confused. The java directory is beneath the one install
> makes for postgresql already, not along side, so for example (based on my
> laptop NT/Cygwin):
>
> /usr/local/pgsql/lib where PGLIB is
> /usr/local/pgsql/lib/java where the .jars are put.
Right. But if --prefix=/usr/local (for example), then we have
/usr/local/lib/libpq.a
/usr/local/include/postgresql/libpq-fe.h
/usr/local/share/postgresql/*.bki
This happens automatically if the prefix does not match 'pgsql|postgres'.
What I would like in that case is
/usr/local/lib/libpq.a (to keep linker happy)
/usr/local/lib/postgresql/java/*.jar (because we are not entitled to
create a directory /usr/local/lib/java, ISTM)
*or* (new idea)
/usr/local/lib/postgresql.jar (since the name provides sufficient
association. But there are other jars.)
Isn't there a convention, or a recommendation from a file system standard
body? Looking at the Ant RPM:
[...]
/usr/share/java/ant.jar
/usr/share/java/jaxp.jar
/usr/share/java/optional.jar
/usr/share/java/parser.jar
I see share/ has its supporters.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Hello everybody,
I'm planning to do a tool in order to reverse engineer from a database
already created to a UML diagram. I'd like to do the test with a PostgreSQL
database, but I've found that DatabaseMetaData and ResultSetMetaData objects
are not fully implemented. This classes are required to do the job I'm
planning, so, does anybody know if will be implemented and released in a short
time?
Thank you very much in advance for your help.
P.D.: if anybody knows about some open source that already does this tasks,
please tell me.
--
Alberto Otero García e-mail: alberto@cometatech.com
Cometa Technologies, S.L. URL: http://www.cometatech.com
At 20:22 09/03/01 +0100, Alberto Otero García wrote: >Hello everybody, > > I'm planning to do a tool in order to reverse engineer from a > database >already created to a UML diagram. I'd like to do the test with a PostgreSQL >database, but I've found that DatabaseMetaData and ResultSetMetaData objects >are not fully implemented. This classes are required to do the job I'm >planning, so, does anybody know if will be implemented and released in a short >time? About 12 methods are left unimplemented in 7.1. However as per the specs they do throw an SQLException to indicate that they are not implemented, which makes us virtually compliant. What methods are you trying to use? > Thank you very much in advance for your help. > >P.D.: if anybody knows about some open source that already does this tasks, >please tell me.