Обсуждение: pgsql-server/. configure configure.in
CVSROOT: /cvsroot
Module name: pgsql-server
Changes by: momjian@postgresql.org 02/09/06 10:31:16
Modified files:
. : configure configure.in
Log message:
Add JAVA_HOME test for Ant.
Bruce Momjian - CVS writes: > Add JAVA_HOME test for Ant. I've been doing fine without. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote:
> Bruce Momjian - CVS writes:
>
> > Add JAVA_HOME test for Ant.
>
> I've been doing fine without.
Your Ant is found without a JAVA_HOME? I tried it here with Ant 1.5 and
the check for Ant failed:
#$ ant
Buildfile: build.xml does not exist!
Build failed
#$ unset JAVA_HOME
#$ ant
Error: JAVA_HOME is not defined correctly.
We cannot execute java
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian writes: > Peter Eisentraut wrote: > > Bruce Momjian - CVS writes: > > > > > Add JAVA_HOME test for Ant. > > > > I've been doing fine without. > > Your Ant is found without a JAVA_HOME? Different systems, different Ants. The old configure check for Ant already detects if Ant doesn't work. There's no need to add more checks to check for other varieties of "don't work". The cause can be found in the config.log file in any case. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Bruce Momjian writes: > > > Peter Eisentraut wrote: > > > Bruce Momjian - CVS writes: > > > > > > > Add JAVA_HOME test for Ant. > > > > > > I've been doing fine without. > > > > Your Ant is found without a JAVA_HOME? > > Different systems, different Ants. The old configure check for Ant > already detects if Ant doesn't work. There's no need to add more checks > to check for other varieties of "don't work". The cause can be found in > the config.log file in any case. Well, the user was confused because they had Ant but it said Ant doesn't work. I don't see the harm in giving them more of a clue than "ant doesn't work". -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian writes: > Well, the user was confused because they had Ant but it said Ant doesn't > work. I don't see the harm in giving them more of a clue than "ant > doesn't work". Yes, "Ant doesn't work. Check config.log for the cause." That's why Ant puts out error messages after all, so we don't have to guess in advance. ;-) -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Well, the user was confused because they had Ant but it said Ant doesn't
> > work. I don't see the harm in giving them more of a clue than "ant
> > doesn't work".
>
> Yes, "Ant doesn't work. Check config.log for the cause." That's why Ant
> puts out error messages after all, so we don't have to guess in advance.
> ;-)
I just did a check by removing the JAVA_HOME check and found that the
Ant failure line suggesting the cause appeared on line 164 of a 235 line
config.log file. It certainly doesn't jump out at me.
I don't understand. Are you trying to save bytes in configure.in? If
we can make problem resolution easier, why wouldn't we do that?
---------------------------------------------------------------------------
configure:2975: checking whether to build Python modules
configure:3003: result: yes
configure:3010: checking whether to build Java/JDBC tools
configure:3021: result: yes
configure:3028: checking for jakarta-ant
configure:3061: result: no
configure:3028: checking for ant
configure:3046: found /usr/local/bin/ant
configure:3058: result: /usr/local/bin/ant
configure:3069: checking whether /usr/local/bin/ant works
configure:3093: /usr/local/bin/ant -buildfile conftest.xml 1>&2
Error: JAVA_HOME is not defined correctly.
We cannot execute java
configure:3096: $? = 1
configure: failed java program was:
public class conftest {
int testmethod(int a, int b) {
return a + b;
}
}
configure: failed build file was:
<project name="conftest" default="conftest">
<target name="conftest">
<javac srcdir="." includes="conftest.java">
</javac>
</target>
</project>
configure:3112: result: no
configure:3116: error: ant does not work
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I don't understand. Are you trying to save bytes in configure.in? If
> we can make problem resolution easier, why wouldn't we do that?
I think he's saying that trying to narrow down the reasons for a failure
is not configure's job: if we buy into that then we'll soon have a
monstrous configure script with a huge number of essentially duplicative
error checks. That costs maintenance effort, not to mention user time
to run a slower script.
Also, the more such checks we provide in the hope of offering a "more
specific" error message, the greater the chance of providing a message
that is more specific and *wrong*, thus misleading the user and causing
him to waste time instead of save it.
"Look in config.log" is good general-purpose advice for understanding
configure-detected problems. I don't think we should spend effort
on special-casing problems that are adequately explained if one looks
in the log.
What *would* be worth doing if it's feasible is to have configure
automatically spit out the relevant section of config.log when it
finds a problem...
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I don't understand. Are you trying to save bytes in configure.in? If > > we can make problem resolution easier, why wouldn't we do that? > > I think he's saying that trying to narrow down the reasons for a failure > is not configure's job: if we buy into that then we'll soon have a > monstrous configure script with a huge number of essentially duplicative > error checks. That costs maintenance effort, not to mention user time > to run a slower script. Well, I didn't advocate adding it for every case but in places where people are experiencing problems, I see no reason not to add a little help. Heck, we do the same in our commands; we don't just throw out a failure from pg_dump and tell them to look at some log somewhere. If we can guess the cause of the error, we tell them. However, if we could do a better job of throwing out the actual error Ant and gcc and others generate, that would be a huge win. > Also, the more such checks we provide in the hope of offering a "more > specific" error message, the greater the chance of providing a message > that is more specific and *wrong*, thus misleading the user and causing > him to waste time instead of save it. > > "Look in config.log" is good general-purpose advice for understanding > configure-detected problems. I don't think we should spend effort > on special-casing problems that are adequately explained if one looks > in the log. Where do we tell them to look in config.log? I have never see it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
pgman wrote:
> > Also, the more such checks we provide in the hope of offering a "more
> > specific" error message, the greater the chance of providing a message
> > that is more specific and *wrong*, thus misleading the user and causing
> > him to waste time instead of save it.
> >
> > "Look in config.log" is good general-purpose advice for understanding
> > configure-detected problems. I don't think we should spend effort
> > on special-casing problems that are adequately explained if one looks
> > in the log.
>
> Where do we tell them to look in config.log? I have never see it.
OK, I found one mention of config.log in configure.in where it tries to
compile a test program. Are you saying you want more mentions of
config.log?
If I could add 50 lines to configure.in that would increase the number
of corrective error messages by 50%, I would do it right now.
---------------------------------------------------------------------------
AC_MSG_CHECKING([test program])
AC_TRY_RUN([int main() { return 0; }],
[ AC_MSG_RESULT(ok)],
[ AC_MSG_RESULT(failed)
AC_MSG_ERROR([[
*** Could not execute a simple test program. This may be a problem
*** related to locating shared libraries. Check the file 'config.log'
*** for the exact reason.]])],
[ AC_MSG_RESULT([cross-compiling])])
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> "Look in config.log" is good general-purpose advice for understanding
>> configure-detected problems. I don't think we should spend effort
>> on special-casing problems that are adequately explained if one looks
>> in the log.
> Where do we tell them to look in config.log? I have never see it.
If we don't tell them that, we certainly should ...
regards, tom lane
Bruce Momjian writes: > I don't understand. Are you trying to save bytes in configure.in? If > we can make problem resolution easier, why wouldn't we do that? That is not the point. You are presuming that JAVA_HOME being set is a prerequisite for Ant to work, which is not the case. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Bruce Momjian writes: > > > I don't understand. Are you trying to save bytes in configure.in? If > > we can make problem resolution easier, why wouldn't we do that? > > That is not the point. You are presuming that JAVA_HOME being set is a > prerequisite for Ant to work, which is not the case. I am not. I am presuming if JAVA_HOME _isn't_ defined, ant will not work. Are there other places in configure where we can point to config.log or give more helpful failures? Perhaps for readline failures. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian writes: > > That is not the point. You are presuming that JAVA_HOME being set is a > > prerequisite for Ant to work, which is not the case. > > I am not. I am presuming if JAVA_HOME _isn't_ defined, ant will not > work. I believe that says the same thing, but it's still a faulty assumption. Depending on which system and distribution you use, Ant runs fine without JAVA_HOME being set. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Bruce Momjian writes: > > > > That is not the point. You are presuming that JAVA_HOME being set is a > > > prerequisite for Ant to work, which is not the case. > > > > I am not. I am presuming if JAVA_HOME _isn't_ defined, ant will not > > work. > > I believe that says the same thing, but it's still a faulty assumption. > Depending on which system and distribution you use, Ant runs fine without > JAVA_HOME being set. Actually, it is not the same because it still goes on to test to see if ant works. It does not assume ant works just because JAVA_HOME is defined. In fact, ant requires version 1.5 so we have even anther test in there before will consider Ant working. I didn't know ant can work without JAVA_HOME defined. Let me see if I can fiddle with the test so it throws out the Ant output on a failure rather than testing for JAVA_HOME. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Peter Eisentraut wrote: > Bruce Momjian writes: > > > > That is not the point. You are presuming that JAVA_HOME being set is a > > > prerequisite for Ant to work, which is not the case. > > > > I am not. I am presuming if JAVA_HOME _isn't_ defined, ant will not > > work. > > I believe that says the same thing, but it's still a faulty assumption. > Depending on which system and distribution you use, Ant runs fine without > JAVA_HOME being set. OK, JAVA_HOME test removed and config.log mention added. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073