> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to