I wanted to check which code has requiring-resolve in bb dependencies since when hitting that at runtime, the image can blow up in size, even when you require the namespace before-hand. I noticed there was one introduced in core.async in the latest release, which is used in bb.
So I wrote this hack:
(def old-requiring-resolve requiring-resolve)
(defmacro static-requiring-resolve [sym]
(prn :sym sym)
`(old-requiring-resolve ~sym))
(alter-var-root #'requiring-resolve (constantly @#'static-requiring-resolve))
(doto #'requiring-resolve (.setMacro))
(require '[babashka.main])
Sure enough, the only occurrence was the one just introduced in core.async 's go macro which isn't used in bb and thus causes no problems.
:sym (quote clojure.core.async.impl.ioc-macros/state-machine)
This might also be useful for detecting resolve , require and find-var usages, but I haven't tried that yet.If you do use the go macro with native image it might be interesting to see how your image size fairs after the core.async update. /cc @ericdallo
thanks, will take a look when bumping on clojure-lsp
I also found nice trick for detecting require as a literal usage (as opposed to the ns form):
;; Enable this for detecting literal usages of require
;; ---
;; (def old-require require)
;; (defmacro static-require [& syms]
;; (when (meta &form)
;; (prn :require &form ))
;; `(old-require ~@syms))
;; (alter-var-root #'require (constantly @#'static-require))
;; (doto #'require (.setMacro))
;; ---
You can also look at the metadata of the form to see if it wasn't a top level form (by approximation, the column should be larger than 1 or so)