I also like this option. I would certainly have mentioned something earlier, but I can't remember configure ever prompting me for anything. This may simply be because I haven't configured from scratch in a long time however, and Java=no is already in my config.cache. I think it is more than enough to have a
Checking for Java.......Java not found (consult ./configure --help) Along with the ability to set the paths with a configure option. BTW, I have a handle on the dump when specifying a label on a Control Panel. > I think it should by default try to build javadx, with a command line > option to turn it off. The user should be able to specify the necessary > info by a command line option, but if not, it should try to divine it for > itself. If it isn't given the info it needs and cannot figure it out, it > should not try to build it. If there's a conventional location for the > installation on a system thats not found by the existing search code, the > search code should be modified to look there also. > > That should solve everybody's problems. If you don't want javadx or don't > have java, you can turn it off (though in the atter case, why bother? It > won't find whats not there, and won't try to build it). If you have a > standard system, it should work without intervention. And if you want > something out of the ordinary - if you have an unconventional installation > or if you want to override the standard system java or if you have a > standard installation on a system that the built-in search doesn't yet > handle, you can deal with it. > > Greg > > David Thompson <[EMAIL PROTECTED]>@opendx.watson.ibm.com on 12/07/99 > 01:16:18 PM > > Please respond to [email protected] > > Sent by: [EMAIL PROTECTED] > > > To: [email protected] > cc: > Subject: Re: [opendx-dev] Prompt for info about java in configure > > > > Not to get too political, but I did ask for help on this when I was first > working through it and got no response from anybody. I sent out several > e-mails about it and it seems you never get a response till somebody > thinks you screwed up. I will try and work on this, but I need some > pointers as to how people think this should work. > > The problem with the java stuff is that there is never a consistent > directory of where java should be installed. That is why Pete wored on > trying to get java to tell him where it is installed. This worked in some > cases, but for any of the java 1.2 it did not, ie the directory structure > has completely changed. The other thing that came out of this was that > some people wanted to be able to use other compilers such as jikes or gcj > (which I have to use on AIX 4.1 as javac bombs with a thread error) > to compile the code. If this is the case, then the flags used on the > compiler (-verbose) to find the location of the jars is not valid and > breaks everything. > > X is different than java. X has been around long enough to develop a sense > of where it should be installed; however java being a complete package in > its own is untarred in whatever directory the user deems necessary. Even > sun has not figured out a good way to automake stuff with jni (as I > researched it on their web pages.) Sun states that the user must > physically give the path to the include directories for the jni. > > I have used many packages that request user input on configure. That is > where I both got the idea and borrowed the source code to develop what now > exists. I added the support to put the flags in to override the user input > so that the user can do unattended builds. > > I can put Pete's code back in and rip my stuff back out and start a second > configure.in that I store somewhere else if that is what you wish. But > what I'd rather do is fix this so that it satisfies all that will be using > it. > > Please respond with the following information: tell me if you just want it > back the way it was and I'll start a separate version of this elsewhere > for others to use, or what you dislike about it with suggestions of what > you think it should do. This will allow me to respond back with either > reasons why that can or cannot be done or illicit help on how to achieve > said goals. > > David > > On Tue, 7 Dec 1999 [EMAIL PROTECTED] wrote: > > > This is directly analogous to the way AC_PATH_X works. X isn't installed > > in the same place on all systems; AC_PATH_X has a list of places to try. > > I'm sure that in its original incarnation, this list wasn't nearly as > > long... rather its been extended as new situations arise. One thing's > for > > sure - it wasn't ripped out and replaced by a requirement that the user > > tell it where to look. Now I have no objection whatsoever to allowing > the > > user to specify where the stuff is, I just object - strenuously - to > > requiring the user to do so. And its certainly not appropriate for you > to > > take it on yourself to unilaterally "fix" Pete's approach. > > > > Greg > > > > -------------------------------------------------------------------- > David L. Thompson e-mail:[EMAIL PROTECTED] > University of Montana/CS Department > Missoula, MT 59812 > Work Phone : (406)243-4793 > > >
