> I am not in favor of creating the directory nor fabricating the > classpath.
Clojure currently creates the directory. Since that appears unintentional, fixing that would go a long way to improving the behavior that caught me. Here's the behavior that cost me a couple of hours of confusion: Goal: test compiling Procedure: Give Clojure a target directory (*compile-path*) that's in classpath and ask it to compile 'clojure.contrib.sql. Expectation: class files in a hierarchy under the target directory. Result: Compilation threw an exception complaining that it couldn't find class definitions. There's a significant caveat in Clojure compilation that was not satisfied here: The target directory must already exist at the time Clojure is launched. Being "in classpath" is not enough. I had specified the target directory as being in classpath via "-cp" when launching Clojure. However (presumably as an optimization), directories specified as being in classpath, but that do not exist at launch time are not actually searched, even if they are subsequently created. In my test: - I started the compile. - Clojure created the target directory and start writing files to it. - The compilation failed complaining about not finding classes--even though I could look on disk and see the corresponding class files right where I had said to put them. - Subsequent tries at compiling would lead to worse, less clear errors (Exception in Initializer being common) - This led me to delete the target directory (a common operation for "clean" targets in build systems) and try again. - Since the conditions were the same gain, I got the same failure again. > This is significant magic, and means that a typo will create a > directory somewhere. The directory need not be fully specified if > it's in the classpath, but where will this create a directory if not > fully specified? Are you saying that *compile-path* is specified relative to classpath? My experience has been that it's an absolute or relative filesystem path that must also be in classpath. > Also, any magic classpath establishment won't be present at runtime, > leading people to think that they were setup correctly when they > weren't. What I'm picturing here is a standalone compiler: a command line that would allow specifying a source dir and a dest dir and a list of libs to compile and would do that without any environmental dependencies. Doing so without the classpath "magic" you object to requires that the target directory already exist before the command line is invoked and that the command line include it explicitly with "-cp" or implicitly through some environment variable. Those are easy things for a build script to get right and ensure happen every time, but it means that a "simple" compile from the command line is error prone and fragile. This standalone compilation capability is different from a more interactive use of the compiler that perhaps you're talking about. In the batch compile case, if I compile some code into classfiles, and then later launch an environment to use those compiled files, but fail to point it at them, that's an easy problem to diagnose and fix. > The current error messages are sufficient. I'm not sure which messages you're talking about here, but the ones I saw were not sufficient to help me diagnose the problem I had. > Remember, anything this feature does has to be explained, and the > explanation is already quite involved. The user-visible behavior I'm talking about is customary behavior for a (batch) compiler. It's not magic and it doesn't require much explanation. Having such a batch compiler would mean that the line in a build script that does a Clojure compilation could be self-contained and have behavior that depends only on it arguments, not on the environment in which it operates. It would be "functional" in that regard with all the virtues that brings. > Simplicity is its own kind of power, and magic != simplicity. I agree. However, there is often a tension between simplicity of use and simplicity of implementation. Both have value. Having a tool satisfy some of its own needs means there's less for me to get right when I use it. If satisfying its own needs is not outrageously complex, that can be a win. With all that in mind though, I'm not sure how feasible it would be to build Clojure tools or apps without a build scripting system of some sort. Such a system can get the compiler's environmental dependencies right every time. Therefore if Clojure is fixed so that it does not create the target directory, that would cover most of the problem I had. Highlighting the Java behavior that "classpath directories must exist at launch time or they will be ignored" clearly would also be very helpful. --Steve --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---