Thanks for the cooperation. Here are some observations and suggestions I hope will be helpful.
Re solaris, consistency on a given ARCH is something we can take advantage of. ARCH is one of the first things we detect. JDKs can be installed virtually anywhere. I don't think a list will be sufficient, possibly it will not even be useful. Searches are out, too: they would have to be too broad. I settled on requiring javac to be in the path. That was fairly common. How about devising a test for Java 1.2 (say something J1.1 can't do) and using the -verbose output in a version-specific way? I'm skeptical sun put in -verbose to help us find java classes and default classpaths. How might we communicate the need (and ideally a proposal) for autoconfigurability to various java groups? Then maybe this will get easier with time instead of harder as now seems to be the case. With Java I found the environment's CLASSPATH needed to be perfect or absent. Configure (when it was automatic) didn't trust the CLASSPATH (it was frequently a leftover from some other installation) and unset it. Sun's javac would then default to a good value based upon its installation. This is more than a bit arbitrary, because the CLASSPATH might have good information in it. Someone who goes to the trouble of setting a good CLASSPATH might want us to look at it, if not immediately, then eventually. Yes, JAVA_ARCH for jni_md.h is a problem. The directory name has meaning, so e.g. if the java installation (say on a fileserver) has multiple subdirs for different archs there is peril in a "find" or */jni_md.h . My take is configure should use an ARCH-specific list of known directory names: the nominal convention was lowercase of uname -s, the linux include dir might be "genunix" instead but I doubt it would be "aix" . Perhaps resort to wildcards as a last resort, but also warn. As for the cases where vendors are thoughtful enough to put the include files in /usr/include, doh... why don't we modify the uipp/java Makefile.am's to use -I/usr/include in the compiles? For non-Sun javas: I noticed when "javac" actually invoked kaffe one could play tricks with the KLASSPATH, and presumably other javas don't look at KLASSPATH. kaffe wouldn't function without a [c,k]lasspath but didn't volunteer what that would be (hopefully, they've fixed that, or will). Probably the task is best postponed until there is a compelling reason to proceed on a given compiler. It should be much easier to use a different jvm at runtime by editing the startserver script. As for editing configure or Makefiles for the locations of the cosmo and netscape classes, I wasn't intending to be coercive here: this was unfinished work and the build did not stop if they were incorrect. I tried briefly and unsuccessfully to force netscape to divulge its classpaths to configure and perhaps someone else would have a good idea. Key concept here is the build was typically on a server platform and e.g. cosmo was normally absent and often incapable of being installed to that platform from a package. Therefore the jars probably got there by being copied by the person building javadx, and s/he could reasonably be expected to tell us where s/he put them. This is a good opportunity to use CLASSPATH or options to configure. I think one thing that might help us with systems unlike our own, is if configure could or would print out a report for the user optionally to send to us, giving us information we think we need to fix or refine our configure. That might include a list of unknowns that the user could supply if s/he knew the answer that configure could not figure out. It could additionally report those crucial knowns that are all too frequently left out of user correspondence. regards, Pete [EMAIL PROTECTED] wrote: > 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 > > [EMAIL PROTECTED] wrote > 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 > 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 > >
