I think that if the necessary stuff cannot be found in a reasonable manner, it should be necessary to specify it on the command line. You could even print a message at the end of configure stating that due to the _very_ unpredictable nature of the Java installations configure cannot find these peices that it needs, you will need to specify them manually. I don't agree with having to edit the Makefiles, or configure, to find stuff, but a configure option is okay. I also don't consider having to use "find / ...." reasonable, as this takes _way_ too much time on my 20G+ filesystem.
> 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 > >
