It seems to me that it there's an appropriate environment variable, then it ought to be tried. If not, then maybe use Pete's approach. If that fails, then fall back on the AC_PATH_X approach - simply a built in list of places to look that gets extended as needed. AC_PATH_X lists 25 places to look.
Greg David Thompson <[EMAIL PROTECTED]>@opendx.watson.ibm.com on 12/07/99 02:15:35 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 Okay, that sounds reasonable and I can try and work on this to get it fixed. Here are the problems that I ran into with Pete's version of the search code and maybe you can give some suggestions to try to fix it. Pete had configure write a little java program and then ran javac -verbose on it to locate which directory the jars were in. This worked okay with java 1.1.x because the jars were located near the root of the java directory and then he could search from there for the include files. But in java 1.2, the jars were down another level of directories, thus you would need to go up a directory and then traverse down. You can imagine the difficulty searching all of this and not knowing what version you're running. Even if you were to use find on the parent directory of the path returned, it could end up searching all of say /local. The other problem was it needs to find jni_md.h which is in a directory named differently on every os. Pete had done some work here to look for it in specific directories, but in the case for linux, the directory is named different on my LinuxPPC, my Alpha Linux, and Linux Intel. Also, Sun on Solaris had decided that java needed to be installed in all of its separate direcotries, ie javac in /usr/bin, jni.h in /usr/include, jars in /opt/java. So I used find to traverse the directory specified by the user to locate jni_md.h, thus avoiding this problem. The next problem was that if someone else used a non-sun javac, the verbose flag does not always work. Thus not being able to even find the starting point. So I guess my questions would be, what is standard? I've got three different systems with three different setups (not by choice). Editting Makefiles was beginning to be a big pain and that is why I made the change. Is the default assumed to be Sun Java 1.1.x running on one specific platform? As for the netscape and cosmo jar files, Pete made it so that you had to edit the paths in the makefiles or put the jars in a location specified by him in the configure. What is your solution? The Netscape jar is a little easier due to the fact that many times it is installed in /usr/lib/netscape, but as for the cosmojar? Just assume it isn't there unless there is a command line option to configure stating where its at? On Tue, 7 Dec 1999 [EMAIL PROTECTED] wrote: > 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 >
