> On Jan 26, 2019, at 12:43 AM, Didier <didi...@gmail.com> wrote: > > Okay, so after reading through the linked issue here: > https://dev.clojure.org/jira/browse/CLJ-322 I'm not sure, as a tool builder, > what is the ideal path forward. > > This is what I seem to understand would be ideal, let me know if I'm wrong: > > 1) AOT compile everything. So basically, always AOT every lib. This is to > make sure that we don't face this issue: > https://dev.clojure.org/jira/browse/CLJ-1544 >
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. > 2) Figure out some mechanism within the built tooling to only include the > classes for which the source exist in the current project being built into > the resulting Jar. Meaning, only namespaces found in the source folder should > have their compiled classes be included into the Jar. You can avoid this by a) not aot compiling or b) compiling only when dependent on things that are compiled, in which case new classes are only your lib. But some tools (like the Maven Clojure plugin) do have the ability to filter which aot’ed classes you include. > > This setup should minimize conflicts, from what I understand. The only thing > I'm not sure about is, are classes compiled with an older version of Clojure > and JDK always going to work with a newer version of Clojure and JDK? As much as possible, yes. But we don’t guarantee it. So again, make the compile decision as late as possible. > >> On Friday, 25 January 2019 22:11:46 UTC-8, Didier wrote: >> 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 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 a topic in the Google > Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/qIA7GoAVtbE/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > 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.
