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
