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