> > I think the key is that if you are going to AOT, then everything you > depend on should be AOTed. The ideal place to do this is when you build the > final application - uberjar and aot the world. To do so, itβs best if libs > never AOT to give app compilers the opportunity to do so. >
The build systems we rely on do not re-build dependent libraries unfortunately, and we don't use uberjar for our deployments either. Which means I can't delay the AOT to the last possible minute. Also, a lot of mixed projects happen, where Java needs the Clojure compiled classes at compile time. So these also can't be delayed AOT. b) compiling only when dependent on things that are compiled > This is what we used to do, as we would compile everything, except Clojure now depends on something that isn't compiled, core specs, which causes conflicts. I'll modify our build tooling to somehow filter classes here, I already excluded the Clojure directory, so that solved our problem related to Clojure. Now I'm just wondering what is best going forward. The transitive AOT compilation thing is a giant pain but there are ways > around it with tooling. > With tooling or with code changes? Because you mentioned writing your namespaces in a way so that gen-classes limit their AOT imact as much as possible. My issue is, I work at a very big company, and I maintain the Clojure build tools internally. I can't guide everyone to refactor their code to isolate their gen-classes, so I need to make the build tool as resilient as possible to all scenarios, assuming no control on the code. So I have two options: 1) AOT everything all the time, but only include the current project classes in the resulting Jar. 2) AOT as little as possible, basically only namespaces with gen-class in them. And also only include the current project classes in the resulting Jar. Unless there is a dependency with protocol, now these should be transiently compiled as well, so I need to give a build options so people could specify to include certain transient namespaces into the Jar, in the case of protocols. I'm personally leaning on one, as it seems like it should work in all cases. Am I forgetting something? Regards! On Saturday, 26 January 2019 15:04:33 UTC-8, Sean Corfield wrote: > > 2) Library B must be AOTed due to a gen-class, but depends on Clojure 1.9 > > > > My approach is to isolate the pieces that need to be AOT compiled to as > few namespaces as possible and have them only depend on other namespaces at > runtime, i.e., avoid :require in the ns clause where possible and use > require/resolve in the AOT-compiled functions to get at the larger body of > Clojure code. And, of course, to try to avoid gen-class as much as possible > too π > > > > The transitive AOT compilation thing is a giant pain but there are ways > around it with tooling. > > > > Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > > ------------------------------ > *From:* clo...@googlegroups.com <javascript:> <clo...@googlegroups.com > <javascript:>> on behalf of Didier <did...@gmail.com <javascript:>> > *Sent:* Friday, January 25, 2019 10:11:45 PM > *To:* Clojure > *Subject:* Re: Issue when moving to Clojure 1.10 > > So I got to the bottom bottom of the problem here. > > This is a scenario: > > 1) Library A depends on library B and Clojure 1.10 > 2) Library B must be AOTed due to a gen-class, but depends on Clojure 1.9 > 3) Library A does not work, because it is now using the Clojure core spec > 1.9 compiled transitively through the Library B AOT, and found in its Jar, > since .class get precedence over source files. > > So, this means that a library with a dependency on another one that is AOT > can cause spec conflicts. > > This is new now that spec is out. And so I first caught this when some of > our libs were using 1.9, and I started moving others to 1.10. > > The way I solved this is by hacking our build, so that the clojure > compiled classes from the AOT don't get included in the Jar after they are > compiled. > > In my opinion, this is a bit of a problem. What would be nice is either to > have a way to compile only a gen-class, and not the namespace that contains > it. Or not compile things transitively. Or maybe just a way for compile to > exclude clojure core namespaces. > > Now, if you depend on libraries that don't need AOT, it is not an issue. > But if you do, it forces you to re-compile all your dependencies and do a > full big bang upgrade to the new Clojure version. You can't just use libs > compiled with older versions of spec. While before, you were able to use > libs compiled with older version of Clojure from packages that use newer > version of Clojure. > > On Wednesday, 16 January 2019 20:47:43 UTC-8, Mark Derricutt wrote: >> >> On 16 Jan 2019, at 18:17, Alex Miller wrote: >> >> Yes, it's one of the downsides of AOT. >> >> I'd say it's not so much a downside of AOT - but of having a single >> output path for classes. I've long wanted Chas's patch to be applied, or >> something like it. >> >> Having everyone reinvent the mechanism whenever they happen to need AOT >> is kind of annoying - rare, but still annoying. >> ------------------------------ >> >> "The ease with which a change can be implemented has no relevance at all >> to whether it is the right change for the (Java) Platform for all time." β >> Mark Reinhold. >> >> Mark Derricutt >> http://www.theoryinpractice.net >> http://www.chaliceofblood.net >> http://plus.google.com/+MarkDerricutt >> http://twitter.com/talios >> http://facebook.com/mderricutt >> > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clo...@googlegroups.com <javascript:> > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+u...@googlegroups.com <javascript:> > 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+u...@googlegroups.com <javascript:>. > For more options, visit https://groups.google.com/d/optout. > -- 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/d/optout.
