Thread: Re: [JDBC] the build

Barry Lind <blind@xythos.com> writes:

> Nic,
>
> Unfortunately I am not well versed in either ant or autoconf configury.
>   I personally build the different versions by changing the JAVA_HOME
> environment variable to point to the jdk I wish to use for building.
> Ant then picks it up and does the 'right' thing.  I personally haven't
> tried building with gcj yet and I don't know if ant has support for gcj.
>
> In general I would say that the driver has moved away from autoconf/make
> and towards ant as the build mechanism.  The role make now plays is
> essentially just the wrapper around ant that ties into the overall
> postgres build mechanism.

Ok, first I should say, I'm a sometime GCJ hacker. I'm not heavily
involved with it, but I am heavily involved with GNU and so I use it a
lot.

So I have an interest here.


The next thing is: GCJ doesn't have a concept of JAVA_HOME. I don't
think jikes or kaffe or kopi has any such concept either.

So that means that JAVAC detection should be either via a normal
autoconf tool or something simpler, like the attached patch.



But that doesn't solve the issue of version selection. I think this
is a fundamental build issue: how do you choose which version of the
driver to build?

As I say, my view is that we should test the target java's version,
and not the version that is being used to run ant.

Would you (or anyone else) have any objection in principle to that?


Nic

Nic,

I don't understand this patch.  From the ant doc I see the following:

 >>It is possible to use different compilers. This can be specified by
 >>either setting the global build.compiler property, which will affect
 >>all <javac> tasks throughout the build, or by setting the compiler
 >>attribute, specific to the current <javac> task. Valid values for
 >>either the build.compiler property or the compiler attribute are:
 >>
 >>    * classic (the standard compiler of JDK 1.1/1.2) – javac1.1 and
 >>javac1.2 can be used as aliases.
 >>    * modern (the standard compiler of JDK 1.3/1.4) – javac1.3 and
 >>javac1.4 can be used as aliases.
 >>    * jikes (the Jikes compiler).
 >>    * jvc (the Command-Line Compiler from Microsoft's SDK for Java /
 >>Visual J++) – microsoft can be used as an alias.
 >>    * kjc (the kopi compiler).
 >>    * gcj (the gcj compiler from gcc).
 >>    * sj (Symantec java compiler) – symantec can be used as an alias.
 >>    * extJavac (run either modern or classic in a JVM of its own).

I don't see 'javac' as a valid option for this parameter.  So I don't
understand why your patch is attempting to set that value.

thanks,
--Barry



Nic Ferrier wrote:
> Barry Lind <blind@xythos.com> writes:
>
>
>>Nic,
>>
>>Unfortunately I am not well versed in either ant or autoconf configury.
>>  I personally build the different versions by changing the JAVA_HOME
>>environment variable to point to the jdk I wish to use for building.
>>Ant then picks it up and does the 'right' thing.  I personally haven't
>>tried building with gcj yet and I don't know if ant has support for gcj.
>>
>>In general I would say that the driver has moved away from autoconf/make
>>and towards ant as the build mechanism.  The role make now plays is
>>essentially just the wrapper around ant that ties into the overall
>>postgres build mechanism.
>
>
> Ok, first I should say, I'm a sometime GCJ hacker. I'm not heavily
> involved with it, but I am heavily involved with GNU and so I use it a
> lot.
>
> So I have an interest here.
>
>
> The next thing is: GCJ doesn't have a concept of JAVA_HOME. I don't
> think jikes or kaffe or kopi has any such concept either.
>
> So that means that JAVAC detection should be either via a normal
> autoconf tool or something simpler, like the attached patch.
>
>
>
> But that doesn't solve the issue of version selection. I think this
> is a fundamental build issue: how do you choose which version of the
> driver to build?
>
> As I say, my view is that we should test the target java's version,
> and not the version that is being used to run ant.
>
> Would you (or anyone else) have any objection in principle to that?
>
>
> Nic
>
>
>
>
> ------------------------------------------------------------------------
>
> Index: src/Makefile.global.in
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/Makefile.global.in,v
> retrieving revision 1.161
> diff -p -u -r1.161 Makefile.global.in
> --- src/Makefile.global.in    2003/04/04 20:42:11    1.161
> +++ src/Makefile.global.in    2003/04/15 16:59:41
> @@ -177,6 +177,9 @@ ifeq ($(GCC), yes)
>    CFLAGS += -Wall -Wmissing-prototypes -Wmissing-declarations
>  endif
>
> +JAVAC    = javac
> +
> +
>  # Kind-of compilers
>
>  YACC = @YACC@
> Index: src/interfaces/jdbc/Makefile
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/interfaces/jdbc/Makefile,v
> retrieving revision 1.38
> diff -p -u -r1.38 Makefile
> --- src/interfaces/jdbc/Makefile    2003/02/12 06:13:04    1.38
> +++ src/interfaces/jdbc/Makefile    2003/04/15 16:59:41
> @@ -22,9 +22,10 @@ build.properties: $(top_builddir)/src/Ma
>      @echo fullversion=$(VERSION) >> build.properties
>      @echo def_pgport=$(DEF_PGPORT) >> build.properties
>      @echo enable_debug=$(enable_debug) >> build.properties
> +    @echo build.compiler=$(JAVAC) >> build.properties
>
>
>
> ------------------------------------------------------------------------
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html

Barry Lind <blind@xythos.com> writes:

> I don't understand this patch.  From the ant doc I see the following:
>
>  >>It is possible to use different compilers. This can be specified by
>  >>either setting the global build.compiler property, which will affect
>  >>all <javac> tasks throughout the build, or by setting the compiler
>  >>attribute, specific to the current <javac> task. Valid values for
>  >>either the build.compiler property or the compiler attribute are:
>  >>
>  >>    * classic (the standard compiler of JDK 1.1/1.2) – javac1.1 and
>  >>javac1.2 can be used as aliases.
>  >>    * modern (the standard compiler of JDK 1.3/1.4) – javac1.3 and
>  >>javac1.4 can be used as aliases.
>  >>    * jikes (the Jikes compiler).
>  >>    * jvc (the Command-Line Compiler from Microsoft's SDK for Java /
>  >>Visual J++) – microsoft can be used as an alias.
>  >>    * kjc (the kopi compiler).
>  >>    * gcj (the gcj compiler from gcc).
>  >>    * sj (Symantec java compiler) – symantec can be used as an alias.
>  >>    * extJavac (run either modern or classic in a JVM of its own).
>
> I don't see 'javac' as a valid option for this parameter.  So I don't
> understand why your patch is attempting to set that value.

You're quite right Barry, sorry.

Here's an emended patch.


Index: src/Makefile.global.in
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/Makefile.global.in,v
retrieving revision 1.161
diff -p -u -r1.161 Makefile.global.in
--- src/Makefile.global.in    2003/04/04 20:42:11    1.161
+++ src/Makefile.global.in    2003/04/16 12:39:53
@@ -177,6 +177,9 @@ ifeq ($(GCC), yes)
   CFLAGS += -Wall -Wmissing-prototypes -Wmissing-declarations
 endif

+JAVAC    =
+
+
 # Kind-of compilers

 YACC = @YACC@
Index: src/interfaces/jdbc/Makefile
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/interfaces/jdbc/Makefile,v
retrieving revision 1.38
diff -p -u -r1.38 Makefile
--- src/interfaces/jdbc/Makefile    2003/02/12 06:13:04    1.38
+++ src/interfaces/jdbc/Makefile    2003/04/16 12:39:53
@@ -16,7 +16,12 @@ majorversion:= $(shell echo $(VERSION) |
 minorversion:= $(shell echo $(VERSION) | sed 's/^[0-9][0-9]*\.\([0-9][0-9]*\).*$$/\1/')

 build.properties: $(top_builddir)/src/Makefile.global
+ifeq "$(JAVAC)" ""
     @echo "# This file was created by 'make build.properties'." > build.properties
+else
+    @echo "# This file was created by 'make build.properties'." > build.properties
+    @echo build.compiler=$(JAVAC) >> build.properties
+endif
     @echo major=$(majorversion) >> build.properties
     @echo minor=$(minorversion) >> build.properties
     @echo fullversion=$(VERSION) >> build.properties
@@ -24,7 +29,7 @@ build.properties: $(top_builddir)/src/Ma
     @echo enable_debug=$(enable_debug) >> build.properties

 all: build.properties
-    $(ANT) -buildfile $(srcdir)/build.xml all
+    $(ANT) -emacs -buildfile $(srcdir)/build.xml all

 install: installdirs build.properties
     $(ANT) -buildfile $(srcdir)/build.xml install \

If you want to test for JAVAC you need to do it in configure.

Nic Ferrier writes:

> Barry Lind <blind@xythos.com> writes:
>
> > I don't understand this patch.  From the ant doc I see the following:
> >
> >  >>It is possible to use different compilers. This can be specified by
> >  >>either setting the global build.compiler property, which will affect
> >  >>all <javac> tasks throughout the build, or by setting the compiler
> >  >>attribute, specific to the current <javac> task. Valid values for
> >  >>either the build.compiler property or the compiler attribute are:
> >  >>
> >  >>    * classic (the standard compiler of JDK 1.1/1.2) – javac1.1 and
> >  >>javac1.2 can be used as aliases.
> >  >>    * modern (the standard compiler of JDK 1.3/1.4) – javac1.3 and
> >  >>javac1.4 can be used as aliases.
> >  >>    * jikes (the Jikes compiler).
> >  >>    * jvc (the Command-Line Compiler from Microsoft's SDK for Java /
> >  >>Visual J++) – microsoft can be used as an alias.
> >  >>    * kjc (the kopi compiler).
> >  >>    * gcj (the gcj compiler from gcc).
> >  >>    * sj (Symantec java compiler) – symantec can be used as an alias.
> >  >>    * extJavac (run either modern or classic in a JVM of its own).
> >
> > I don't see 'javac' as a valid option for this parameter.  So I don't
> > understand why your patch is attempting to set that value.
>
> You're quite right Barry, sorry.
>
> Here's an emended patch.
>
>
> Index: src/Makefile.global.in
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/Makefile.global.in,v
> retrieving revision 1.161
> diff -p -u -r1.161 Makefile.global.in
> --- src/Makefile.global.in    2003/04/04 20:42:11    1.161
> +++ src/Makefile.global.in    2003/04/16 12:39:53
> @@ -177,6 +177,9 @@ ifeq ($(GCC), yes)
>    CFLAGS += -Wall -Wmissing-prototypes -Wmissing-declarations
>  endif
>
> +JAVAC    =
> +
> +
>  # Kind-of compilers
>
>  YACC = @YACC@
> Index: src/interfaces/jdbc/Makefile
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/interfaces/jdbc/Makefile,v
> retrieving revision 1.38
> diff -p -u -r1.38 Makefile
> --- src/interfaces/jdbc/Makefile    2003/02/12 06:13:04    1.38
> +++ src/interfaces/jdbc/Makefile    2003/04/16 12:39:53
> @@ -16,7 +16,12 @@ majorversion:= $(shell echo $(VERSION) |
>  minorversion:= $(shell echo $(VERSION) | sed 's/^[0-9][0-9]*\.\([0-9][0-9]*\).*$$/\1/')
>
>  build.properties: $(top_builddir)/src/Makefile.global
> +ifeq "$(JAVAC)" ""
>      @echo "# This file was created by 'make build.properties'." > build.properties
> +else
> +    @echo "# This file was created by 'make build.properties'." > build.properties
> +    @echo build.compiler=$(JAVAC) >> build.properties
> +endif
>      @echo major=$(majorversion) >> build.properties
>      @echo minor=$(minorversion) >> build.properties
>      @echo fullversion=$(VERSION) >> build.properties
> @@ -24,7 +29,7 @@ build.properties: $(top_builddir)/src/Ma
>      @echo enable_debug=$(enable_debug) >> build.properties
>
>  all: build.properties
> -    $(ANT) -buildfile $(srcdir)/build.xml all
> +    $(ANT) -emacs -buildfile $(srcdir)/build.xml all
>
>  install: installdirs build.properties
>      $(ANT) -buildfile $(srcdir)/build.xml install \
>
>

--
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:

> If you want to test for JAVAC you need to do it in configure.

For clarification: Yes, we could use the GNU autotools java macros as
well. But postgresql's jdbc library is built using the ANT project
builder tool and it selects the compiler for us if we give it a name.

The JAVAC variable in the Makefile.in is therefore designed to allow
overriding by the user when running the make, thus:

   ./configure --with-java ; make JAVAC=gcj

will build the jdbc library with gcj.

A full java compiler detection system might be overload.


Nic

Nic Ferrier writes:

> The JAVAC variable in the Makefile.in is therefore designed to allow
> overriding by the user when running the make, thus:
>
>    ./configure --with-java ; make JAVAC=gcj
>
> will build the jdbc library with gcj.

And then if you make a change and run make again but forget to specify the
same Java compiler, you get a mess.  Specifying variables on the make
command line has been rejected as error-prone a long time ago.

--
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:

> Nic Ferrier writes:
>
> > The JAVAC variable in the Makefile.in is therefore designed to allow
> > overriding by the user when running the make, thus:
> >
> >    ./configure --with-java ; make JAVAC=gcj
> >
> > will build the jdbc library with gcj.
>
> And then if you make a change and run make again but forget to specify the
> same Java compiler, you get a mess.  Specifying variables on the make
> command line has been rejected as error-prone a long time ago.

I agree. If I ruled the world everything would be autotools.

The proposed patch is a hack. But it is a hack with a purpose, the
desire to do this is, after all, not exactly universal right now.

As I'm sure you know, a better solution would be to invent some kind
of autoconf macro to achieve the same purpose, ie: the specification
of the compiler to Ant. If it was done in autoconf then overrides
would be possible at ./configure time.

As Barry has pointed out, what we want the JAVAC variable (we'll
probably change the variable's name) to contain is not the filename
of a compiler executable but a symbolic name to be recognized by Ant;
so none of the existing autotools Java macros is suitable.

And I don't have the time _right_ now to write such a macro. I might
in the future.


So, is the hack method totally unacceptable do you think? If not I'll
submit it as part of a patch for the java build that I'll be doing
this evening.

If it is unacceptable then we'll have to wait for somebody to write a
macro before compiling with gcj becomes easier (and I think that
would be a pity).



Nic