This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (29)
- # boot (17)
- # calva (1)
- # cider (31)
- # cljs-dev (3)
- # clojure (169)
- # clojure-europe (1)
- # clojure-france (1)
- # clojure-russia (40)
- # clojure-serbia (3)
- # clojure-uk (42)
- # clojurescript (19)
- # clr (3)
- # core-async (7)
- # core-typed (3)
- # cursive (43)
- # datascript (4)
- # datomic (2)
- # dirac (4)
- # emacs (2)
- # fulcro (85)
- # funcool (1)
- # nrepl (5)
- # off-topic (14)
- # shadow-cljs (28)
- # spacemacs (5)
- # tools-deps (2)
Hey @flyboarder, yeah - there's one class that needs to be aot compiled for the project to work properly. I referenced that
:namespace in the
aot task - so I was a bit surprised that adding unrelated dependencies caused the task to break (figured the task should have only applied to the referenced namespace). Have you seen this before?
ie. the compiler is getting a symbol when it’s expecting a sequence of some kind - the full stack trace should pinpoint the line where the call is broken, but I imagine that’s not useful since the problem is likely the deps.edn file
Also, if you can pare it back to a version that works and then identify the single dependency you added that breaks things, that would be immensely helpful.
(as an aside, the intent of
boot-tools-deps is per the readme: "The primary use case for boot-tools-deps is that your project runs with clj -- so all of its dependencies are managed via deps.edn files, with aliases as appropriate -- and you want to bring Boot tooling to that project, in addition." -- it is not intended to support an arbitrary Boot project where you want just the dependencies in a
I would strongly advise either: a) using
deps.edn completely independently of Boot or b) using Boot completely independently of
deps.edn if you have needs beyond the basic use case.
Also @mattyulrich one thing to bear in mind is that AOT is transitive: when you compile a namespace, it will also compile everything that namespace requires in.
Thanks for all the info, @seancorfield! Maybe you're right and I'm using
boot-tools-deps inappropriately; I'm using nearly exclusive boot tooling in my project; I'm really only using
deps.edn to try and leverage dependency resolution from a git sha - is this possible in boot alone? If so, I'll eschew the
deps.edn bit and stick with boot. This project integrates with protobuf, and I'm using a forked version of
clojusc/protobuf - to work from the repl, I need to aot
protobuf.impl.flatland.core. The project worked fine until I added either ring, or compojure (which transitively includes ring) to the
deps.edn. Let me try and get a stripped down version of what I'm doing in github to share and you can let me know if I'm going about this all wrong. 🙂
I'd suggest trying to do everything from
clj alone, to be honest. No, you can't resolve Git deps from Boot as far as I know @mattyulrich
:paths with both
"src" -- and there's a
user.clj file that compiles the namespace that needs to be AOT'd.
I haven't specifically tried to build that project with a
deps.edn-based JAR-builder but I think that would work...
Ok - I've been spending a few hours trying to reproduce in the small and it's not happening. (basic idea here: https://github.com/mattyulrich/aot-prob) So - as you suggest, it's likely something small somewhere with bad error messages. I'm going to play with my trouble project a bit and see if I can identify where it's breaking down. Ultimately, I'd like to add a hoplon/castra frontend to this - which is one of the compelling reasons to use boot tooling. I'll take a look to see if I can do this kind of work with only clj and take a look at your cfml-interop library in the meantime. Thanks, @seancorfield - if I can identify what's happening, I'll post back here with the updated git repo.