Thread: 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
Attachment
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