Обсуждение: the build

Oh woe! the awful plight of the java build maker.

The jdbc build works really well, for the majority of cases. But I'm
just playing with building postgresql with GCJ (the GNU java
compiler).

The build is badly broken when it comes to dealing with GCJ:

- the compiler is not passed through to the ANT build, it's not even
  autodetected.
  It's fairly easy to fix this problem though, but it would normally
  entail switching to the autoconf java macros for java compiler
  detection.

- the version of the library to build is decided by testing the
  version of java that is running ant, not the version of java that
  is being used as the compiler.

- the version of java is used to decide which version of the drivers
  get built. This prevents cross compiling.


If this was an autoconf/automake build we'd use some macros to decide
which version to build by running a small compile to check what
classes were available.

I could write an autconf/automake build... but it's never going to
make ant redundant because windows people use ant (I'm guessing).


Does anyone have any ideas how I might make the build process more
generic whilst not breaking ant compatibility?



Nic

Nic,

I am not sure exactly what your design aims are - I personally tend to set
reasonable defaults if possible and let the individuals doing the compiling
override whatever they like.  If you can't set defaults then would it be
reasonable to build all configurations (at least those that are possible
with the available compiler)?

I noticed you haven't used the compiler attribute of the javac task.  Either
I have completely misunderstood what you are trying to do or you have a
specific reason for not doing this.

paul

----- Original Message -----
From: "Nic Ferrier" <nferrier@tapsellferrier.co.uk>
To: <pgsql-jdbc@postgresql.org>
Sent: Tuesday, April 15, 2003 8:19 PM
Subject: [JDBC] the build


> Oh woe! the awful plight of the java build maker.
>
> The jdbc build works really well, for the majority of cases. But I'm
> just playing with building postgresql with GCJ (the GNU java
> compiler).
>
> The build is badly broken when it comes to dealing with GCJ:
>
> - the compiler is not passed through to the ANT build, it's not even
>   autodetected.
>   It's fairly easy to fix this problem though, but it would normally
>   entail switching to the autoconf java macros for java compiler
>   detection.
>
> - the version of the library to build is decided by testing the
>   version of java that is running ant, not the version of java that
>   is being used as the compiler.
>
> - the version of java is used to decide which version of the drivers
>   get built. This prevents cross compiling.
>
>
> If this was an autoconf/automake build we'd use some macros to decide
> which version to build by running a small compile to check what
> classes were available.
>
> I could write an autconf/automake build... but it's never going to
> make ant redundant because windows people use ant (I'm guessing).
>
>
> Does anyone have any ideas how I might make the build process more
> generic whilst not breaking ant compatibility?
>
>
>
> Nic
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org

"Paul Sorenson" <pauls@classware.com.au> writes:

> Nic,
>
> I am not sure exactly what your design aims are - I personally tend to set
> reasonable defaults if possible and let the individuals doing the compiling
> override whatever they like.  If you can't set defaults then would it be
> reasonable to build all configurations (at least those that are possible
> with the available compiler)?
>
> I noticed you haven't used the compiler attribute of the javac task.  Either
> I have completely misunderstood what you are trying to do or you have a
> specific reason for not doing this.

Note that I didn't make the build.

It's easy to add gcj as a compiler, as long as there is some way of
telling make that it should be the compiler. The traditional way with
autotools is to do it with a macro JAVAC which can autodetect the
java compiler from the path and from conventional homes but be
overriden with an env var from the user, this:

  ./configure --with-java

might find /usr/local/bin/javac but

  JAVAC=jikes ./confgure --with-java

would find the jikes from the PATH.

This is easy to fit into postgresql's autoconf build, simply add the
macros and a line to the build.properties specifying the
build.compiler.


The other bits are more difficult, and more important IMHO because
they effect cross compilation which is something one wants to do
sometimes when testing code for release.


Nic

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.

thanks,
--Barry

Nic Ferrier wrote:
> Oh woe! the awful plight of the java build maker.
>
> The jdbc build works really well, for the majority of cases. But I'm
> just playing with building postgresql with GCJ (the GNU java
> compiler).
>
> The build is badly broken when it comes to dealing with GCJ:
>
> - the compiler is not passed through to the ANT build, it's not even
>   autodetected.
>   It's fairly easy to fix this problem though, but it would normally
>   entail switching to the autoconf java macros for java compiler
>   detection.
>
> - the version of the library to build is decided by testing the
>   version of java that is running ant, not the version of java that
>   is being used as the compiler.
>
> - the version of java is used to decide which version of the drivers
>   get built. This prevents cross compiling.
>
>
> If this was an autoconf/automake build we'd use some macros to decide
> which version to build by running a small compile to check what
> classes were available.
>
> I could write an autconf/automake build... but it's never going to
> make ant redundant because windows people use ant (I'm guessing).
>
>
> Does anyone have any ideas how I might make the build process more
> generic whilst not breaking ant compatibility?
>
>
>
> Nic
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>

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

On Tue, Apr 15, 2003 at 11:19:11AM +0100, Nic Ferrier wrote:

> - the version of java is used to decide which version of the drivers
>   get built. This prevents cross compiling.

I don't know if you're going to be able to get around this one.

For example, the JDBC1 driver won't build under 1.4 as the concrete
implementations of the JDBC interfaces only implement the JDBC1 parts while
1.4's java.sql interfaces are JDBC3 .. so the compiler will complain that
the concrete class should be abstract.

You *might* be able to cross-compile to an earlier JDBC version by providing
an alternate java.sql.* but this sounds a bit hairy (I think that Sun has a
"standard" mechanism for this in their 1.4 VMs, but I haven't looked at the
details) -- but you won't have any guarantees that you're not using an API
specific to your compile VM somewhere else.

-O

Oliver Jowett <oliver@opencloud.com>
 writes:

> On Tue, Apr 15, 2003 at 11:19:11AM +0100, Nic Ferrier wrote:
>
> > - the version of java is used to decide which version of the drivers
> >   get built. This prevents cross compiling.
>
> I don't know if you're going to be able to get around this one.
>
> For example, the JDBC1 driver won't build under 1.4 as the concrete
> implementations of the JDBC interfaces only implement the JDBC1 parts while
> 1.4's java.sql interfaces are JDBC3 .. so the compiler will complain that
> the concrete class should be abstract.
>
> You *might* be able to cross-compile to an earlier JDBC version by providing
> an alternate java.sql.* but this sounds a bit hairy (I think that Sun has a
> "standard" mechanism for this in their 1.4 VMs, but I haven't looked at the
> details) -- but you won't have any guarantees that you're not using an API
> specific to your compile VM somewhere else.

The problem is the detection of which version to build. If this were
an autotools project (eg: autoconf/automake/etc...) I'd write a small
autoconf (m4) macro to test the target platform, eg:

  cat > version_1_2_test.java << ENDJAVA12TEST
  import java.sql.*;
  public class version_1_2_test
  {
  public static void main (String argv)
  {
     Blob b = null;
  }
  }
  ENDJAVA12TEST
  $(JAVAC) -d . version_1_2_test.java
  if [ $? -ne 0 ]
    -- not version 1.2
  fi


With java of course it's even easier because you can use reflection
to discover the feature, it might be possible to write either an ANT
task or an autoconf macro to acomplish a reflection based test.

But the important point is that the test MUST be done to the target
java platform and NOT the platform running ant as it is done at the
moment.

This is what I'm trying to find out if people have objections to.


Nic

Nic Ferrier wrote:
> But the important point is that the test MUST be done to the target
> java platform and NOT the platform running ant as it is done at the
> moment.

Why isn't the platform running ant the same as the target platform?

ISTM that ant is designed to support multiple compilers (at least javac
and jikes) so supporting gcj shouldn't be to difficult.

Are you trying to use gcj to compile to bytecode or to native?

thanks,
--Barry

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:

> Nic Ferrier wrote:
> > But the important point is that the test MUST be done to the target
> > java platform and NOT the platform running ant as it is done at the
> > moment.
>
> Why isn't the platform running ant the same as the target platform?

Because you might well want to cross compile, maybe use javac to compile
code to run on gij (the GNU java interpreter).


> ISTM that ant is designed to support multiple compilers (at least javac
> and jikes) so supporting gcj shouldn't be to difficult.

Yes, I can compile the code with GCJ. I'm already doing that. But
choosing which version to compile is more difficult.

>
> Are you trying to use gcj to compile to bytecode or to native?

bytecode. for now. It works. But the integration with the build is
zero.

Are you wedded to using ANT to auto-select the version to build? If
so would you accept an ANT task to do the selection properlt (ie:
based on the target VM).


Nic

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 \

Nic,

I think I would prefer using something other than JAVAC as the name.
Perhaps something like JAVA_COMPILER would be better.  Ant calls it
COMPILER but that clearly would be confusing.  JAVAC doesn't convey that
this is the type of compiler, instead it seems to indicate the compiler
executable name.

On the broader questions you are raising let me add the following comments.

I am not against adding an ant task, but I don't know what that entails
or what the implications are for the build environment.  So in principal
I am OK with the idea, but reserve final judgment until after I
understand better the implications of it.

Wouldn't it be simpler (although not as eligant) to just have different
targets for each of the jdbc versions?  If the target was the default
the current logic would be used, else if it was specified then just go
ahead and build that specific version.  This does get a bit complicated
with the different possible builds (jdbc1, jdbc2, jdbc2ee, jdbc2+ssl,
jdbc2ee+ssl, jdbc3), but I don't currently build all of these
permutations for posting to the website anyway, so I am not sure we need
them all to be available for cross-compilation either.

thanks,
--Barry

Nic Ferrier wrote:
> 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 \
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>

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

Barry Lind <blind@xythos.com> writes:

> Nic,
>
> I think I would prefer using something other than JAVAC as the name.
> Perhaps something like JAVA_COMPILER would be better.  Ant calls it
> COMPILER but that clearly would be confusing.  JAVAC doesn't convey that
> this is the type of compiler, instead it seems to indicate the compiler
> executable name.

It's just that JAVAC is the recognized name used by the
auto-tools. It would mean consistency with the rest of the Make
environment (if not the Ant environment, Ant really doesn't care).


> On the broader questions you are raising let me add the following comments.
>
> I am not against adding an ant task, but I don't know what that entails
> or what the implications are for the build environment.  So in principal
> I am OK with the idea, but reserve final judgment until after I
> understand better the implications of it.

Ok. I'll look into developing one. I don't know much about it either
except that the task API has been pretty static and, since the tasks
are just bytecode, if you have Ant you can run any task.


> Wouldn't it be simpler (although not as eligant) to just have different
> targets for each of the jdbc versions?  If the target was the default
> the current logic would be used, else if it was specified then just go
> ahead and build that specific version.  This does get a bit complicated
> with the different possible builds (jdbc1, jdbc2, jdbc2ee, jdbc2+ssl,
> jdbc2ee+ssl, jdbc3), but I don't currently build all of these
> permutations for posting to the website anyway, so I am not sure we need
> them all to be available for cross-compilation either.

Personally I think we need to clean up the Ant build anyway. IMHO
it's a bit of a mess, I don't understand how to make it re-compile
and AbstractJdbc1 file when I'm working on Java2 and I have to
re-hack the build cript each time (I think you [or someone else]
explained it to me once but it still wasn't very clear).

So I'd be happy to look at creating explicit targets for jdbc1,
jdbc2, jdbc3 and for the other permutations (which I'm sure we could
handle smartly).



Nic

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 wrote:
> Barry Lind <blind@xythos.com> writes:
>
>
>>Nic,
>>
>>I think I would prefer using something other than JAVAC as the name.
>>Perhaps something like JAVA_COMPILER would be better.  Ant calls it
>>COMPILER but that clearly would be confusing.  JAVAC doesn't convey that
>>this is the type of compiler, instead it seems to indicate the compiler
>>executable name.
>
>
> It's just that JAVAC is the recognized name used by the
> auto-tools. It would mean consistency with the rest of the Make
> environment (if not the Ant environment, Ant really doesn't care).
>
But isn't the meaning of JAVAC in the auto-tools different than you are
using it for here?  Doesn't it mean the name of the executable that
compiles java source in the auto-tools environment?  In ant it it a key
word that represents the type of compiler so that you have things like
'classic' and 'modern' which are very different than anything the
auto-tools would be generating.

>
>
>>On the broader questions you are raising let me add the following comments.
>>
>>I am not against adding an ant task, but I don't know what that entails
>>or what the implications are for the build environment.  So in principal
>>I am OK with the idea, but reserve final judgment until after I
>>understand better the implications of it.
>
>
> Ok. I'll look into developing one. I don't know much about it either
> except that the task API has been pretty static and, since the tasks
> are just bytecode, if you have Ant you can run any task.
>
How would this work?  Would the source for the task be part of cvs then
a bootstrap process would be invoked to build the task first, then run
ant a second time using that task?  It sounds like it could be very complex.

>
>
>>Wouldn't it be simpler (although not as eligant) to just have different
>>targets for each of the jdbc versions?  If the target was the default
>>the current logic would be used, else if it was specified then just go
>>ahead and build that specific version.  This does get a bit complicated
>>with the different possible builds (jdbc1, jdbc2, jdbc2ee, jdbc2+ssl,
>>jdbc2ee+ssl, jdbc3), but I don't currently build all of these
>>permutations for posting to the website anyway, so I am not sure we need
>>them all to be available for cross-compilation either.
>
>
> Personally I think we need to clean up the Ant build anyway. IMHO
> it's a bit of a mess, I don't understand how to make it re-compile
> and AbstractJdbc1 file when I'm working on Java2 and I have to
> re-hack the build cript each time (I think you [or someone else]
> explained it to me once but it still wasn't very clear).
>
> So I'd be happy to look at creating explicit targets for jdbc1,
> jdbc2, jdbc3 and for the other permutations (which I'm sure we could
> handle smartly).
>
I certainly agree that improvements could be made.  I look forward to
seeing what you come up with.

As far as re-compiling the AbstractJdbc1* stuff, I do a 'make clean;
make' to accomplish this.  Ugly, but it works.

thanks,
--Barry

Barry Lind <blind@xythos.com> writes:

> But isn't the meaning of JAVAC in the auto-tools different than you are
> using it for here?  Doesn't it mean the name of the executable that
> compiles java source in the auto-tools environment?  In ant it it a key
> word that represents the type of compiler so that you have things like
> 'classic' and 'modern' which are very different than anything the
> auto-tools would be generating.

You're right of course.


> > Ok. I'll look into developing one. I don't know much about it either
> > except that the task API has been pretty static and, since the tasks
> > are just bytecode, if you have Ant you can run any task.
> >
> How would this work?  Would the source for the task be part of cvs then
> a bootstrap process would be invoked to build the task first, then run
> ant a second time using that task?  It sounds like it could be very
> complex.

It wouldn't work like that. We'd set CLASSPATH to include our
pre-compiled ant task (there would be an Make/ANT target to build it
from source as well) in the call to ANT. It would then be available
to the build.


> I certainly agree that improvements could be made.  I look forward to
> seeing what you come up with.

I've got something that separates the targets out at the expense of
making the compilation specification include based. I'll make a proper
patch and send it tonight.


> As far as re-compiling the AbstractJdbc1* stuff, I do a 'make clean;
> make' to accomplish this.  Ugly, but it works.

Ah yes. That's what I do, and then I hack the build file so I don't
have to  /8->



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