Some people have had issues with c.c.logging in that it looks for a suitable logging implementation at macro-expansion-time (by simply trying to import the necessary classes), which thus also occurs during AOT compilation; the down-side is that if the desired logging lib is not on the classpath during compilation, the java.util.logging implementation gets selected into the compiled code. There are solutions to move this choice to runtime, though it adds some overhead to every invocation, even if the respective log level is disabled.
It occurs to me it would be very nice indeed if I could provide alternate implementations depending on whether the clojure code was being executed as a .clj or an AOTC'd .class file. Knowing this would further allow the specification of env vars to influence the resulting code, e.g., telling c.c.logging that even though it's being AOTC'd, it can choose the logging impl right away since it's on the classpath (thus negating the performance hit of a runtime selection). Does anyone have a sense of whether or not this is possible already or, if not, worth doing?
-- 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
