On Sat, Feb 9, 2013 at 4:20 PM, vemv <v...@vemv.net> wrote:
> Then library consumers can specify either [com.example/awesomelib "1.4.0"],
> [com.example "1.4.0-DEBUG"], or [com.example "1.4.0-NO-DEBUG"] in their
> :dependencies vector, in the corresponding project.clj.
> If no version directive is specified, "DEBUG" would be chosen unless
> specified otherwise in profiles.clj: {:user {:debug-dependencies false}}
>
> Does it sound good enough?I like this idea a lot, but I would like to point out that the flags you're talking about apply at compile time, which is usually not the same as jar distribution time. Consider it in terms of these: * Compilation during development * Compilation for library distribution (very rare) * Compilation for application distribution Granted there are a few libraries which require AOT compilation before distribution, but these are few and far between. I'm curious now as to what the percentage is here; maybe I can scan through the Clojars corpus. I would expect it to be well under 5%; perhaps even under 1%. In addition, libraries that do AOT already have to deal with incompatibilities between major Clojure versions, so they probably already distribute a set of versions compiled slightly differently. Typically in Maven repositories these are handled by the :classifier rather than the version, but the end result is the same; the group id, artifact id, version, classifier, and packaging/extension are all part of what uniquely identifies an artifact. The problem is that since different classifiers distinguish different artifacts, adding the "nodebug" classifier will not cause the default version to be excluded; you'll need an explicit :exclusion for it. This can get hairy if things are being pulled in transitively. Anyway, the tl;dr is that this is a setting which won't be needed for distribution when considering the vast majority of jars. For those few that do need it, it would probably be simpler just to force a recompile when the entire application is compiled rather than dealing with classifiers. In fact, defaulting to leaving them off and making it the responsibility of Leiningen (or whatever is launching the development environment) to turn them on during development time might be the simplest thing. -Phil -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
