On Mon, Jul 4, 2011 at 3:14 AM, Konrad Hinsen <konrad.hin...@fastmail.net> wrote: > AOT compilation: My case is probably a bit complex in this respect. I need > AOT compilation only because I want to produce an executable jar, so there > is at least one namespace that must be AOT compiled. For building that > executable jar, it doesn't matter if everything else is AOT compiled as > well. But I want to be able to build a standard library jar with just the > Clojure code to make sure it works with future Clojure releases. One > solution would be to have two completely different builds, one for the > executable jar and one for the library version, but using the same set of > source code files.
You seem to want to make two things: a library and an application. For that, I think it's only proper if you have two build scripts, since you have two build artifacts. Indeed, the application may be better off depending on the library than directly incorporating its source code as some of its own. >> For the record, leiningen can do this by adding a repository with a >> file:/// URL; it's just not documented because I think it's a bad idea. > > With absolute filenames in a URL, it's indeed a bad idea because the project > becomes specific to a machine/installation. What I'd like to see instead is > a project-local repository, e.g. a "deps" folder with jar files and source > code directories. > > There are several reasons why I want dependencies outside of repositories: > > 1) Simplicity. I want to distribute a single tar file to collaborators (who > are new to Clojure and the JVM world) containing all dependencies and build > scripts. I want to tell them "install <name of build tool>, take this file, > play with the source code, and just type <build-command> to build an > executable". They will struggle with a new language and a new environment > already, there's no need to add the complexities of repositories. This is what I meant about avoiding unnecessary ceremony. > To make it worse, we all live behind proxies that require messy configuration > for tools like Maven. > > 2) Network independence. I often work without Internet access, and I don't > want to be blocked at some point because some build tool wants to access > some repository to see if my version is still current. The above provide some reasons why the build process should not *require* an internet connection if all dependencies are already available locally. I don't have a problem if some build tool checks for updates, so long as it treats a failed check the same as finding there's no update, give or take a non-fatal warning or two. On the other hand, the result on actually finding an update should probably be a user prompt in interactive mode and a build without the update in batch mode. Otherwise the update, if it breaks backward compatibility, could break the build. A build that worked yesterday and breaks today without one having changed any local files, neither the build script nor the sources nor anything else, is going to be a head-scratcher to deal with, and in many contexts time is money. > 3) Confidentiality. Sometimes I work with unpublished code that I promised > not to give to anyone else. I can't keep that promise if the code leaves my > machine in any way. For that case, the file:/// repository would of course > be fine. Presumably also for network-independence and avoiding annoying proxies. But if it needs an absolute path, that may* break the "just tar up the source tree and mail it to someone" capability and forces even small collaborative projects to set up and use some kind of code repository instead. As I've argued elsewhere, repository use scales poorly at the small-project end, unsurprisingly since repositories were specifically invented as a tool to make large-scale projects with huge numbers of collaborators and vast reams of code manageable. Using a high-falutin' version control system for 12kloc and three developers is like using a bazooka to swat a fly, a top-of-the-line Oracle database product on expensive iron to track your personal expenses and balance your checkbook, or hashmaps instead of arraymaps to store little three-key objects that number in the tens of thousands. :) * Unix filesystems seem to be standardized enough in layout that using absolute paths of \usr\src\whatever and suchlike may be viable. Except that it won't work for a collaborator whose machine runs Windows, and, worse, it requires working as root or else letting unprivileged users create executables in world-readable places -- ick. > I'd prefer one build system to two separate layers, one of which I'd write > myself. Moreover, most of my dependencies are not projects, but simply jar > files picked up from various sources. Indeed, Maven-based stuff seems oriented around the assumption that any third-party dependencies you will have, in particular, will generally be publicly hosted on Maven repositories themselves rather than just a ten-cent web site or Blogspot article or Facebook page with a .jar download link. Another case of not scaling well at the low-size end of things, or at the shallow end of the skill pool or the low end of the budget scale for that matter. (Setting up a Facebook profile or a blog on an existing service: free and easy. Uploading a jar file you built to Rapidshare or some other such site and posting the link: free and easy. Setting up some kind of publicly-visible code repository: expensive and complex. Using an existing repository service site: perhaps free and perhaps less complex, but still fairly complex.) But this time biting the small-time library's users rather than its small-time developer... -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
