How would I specify the javac options for aot compilation with depstar?
I am trying to set the target language level of the output.
@markbastian Not quite sure what you're asking here: javac
is used for compiling Java source code, not Clojure.
Doesโt the aot option defer to javac?
AOT is Clojure compilation, not Java compilation.
javac
is for compiling Java.
Ah, got it.
If you have Java sources, you have to run javac
yourself to compile them to .class
files that can be included on the classpath if needed.
My issue was I had a jar I was trying to deploy to google app engine. It support jvm11 and I am currently using jdk15 locally. I wasnโt sure what bytecode level was being generated and wanted to make sure it was ok. But the clojure compiler I am assuming uses jdk8, right?
clojure itself is compiled into java8 compatible bytecode
java8+ that is
so yeah
AOT compilation in depstar
shells out and runs Clojure itself via java -cp ... clojure.main -e "(compile,'the-ns)"
effectively. You can specify :jvm-opts
to depstar
and it will pass those to the java
command, which was added as a way to set JVM properties that the Clojure compiler respects. See https://clojure.org/reference/compilation#_compiler_options
The :jvm-opts
exec arg was added in depstar
2.0.187 so it's fairly new.
@markbastian You can try my app template based on depstar
for aot compilation and compiling java sources. It is still under development but already works.
There you can set the target level of compilation.
https://github.com/redstarssystems/rssysapp
to download the template use this command: clojure -X:clj-new :template rssysapp :name myname/myapp01 :snapshot true
(assuming you have :clj-new
as an alias -- the clj-new
README would lead folks to :new
instead, as would my dot-clojure repo)
depstar-newbie question: I want to provide project-specific aliases for the creation of a jar and uberjar. For each, I want to specify the artifact-id, group-id, and version. Is there some way to define those values once in my deps.edn file, and in the :exec-args
of my jar/ubersjar aliias the value of the key :group-id
would be a reference to where I defined this elsewhere in this deps.edn file?
@dcj I'm not quite understanding what you're asking...
An alias can specify :exec-args
and when you use that alias, those arguments will be used.
(! 798)-> clojure -Sdeps '{:aliases {:a {:exec-args {:a 1}} :b {:exec-args {:b 2}} :c {:exec-args {:a 3 :c 3}}}}' -X:a clojure.core/println
{:a 1}
(! 799)-> clojure -Sdeps '{:aliases {:a {:exec-args {:a 1}} :b {:exec-args {:b 2}} :c {:exec-args {:a 3 :c 3}}}}' -X:a:b clojure.core/println
{:a 1, :b 2}
(! 800)-> clojure -Sdeps '{:aliases {:a {:exec-args {:a 1}} :b {:exec-args {:b 2}} :c {:exec-args {:a 3 :c 3}}}}' -X:a:b:c clojure.core/println
{:a 3, :b 2, :c 3}
(! 801)-> clojure -Sdeps '{:aliases {:a {:exec-args {:a 1}} :b {:exec-args {:b 2}} :c {:exec-args {:a 3 :c 3}}}}' -X:c:a clojure.core/println
{:a 1, :c 3}
They merge in alias order.
:uberjar {:replace-deps {com.github.seancorfield/depstar {:mvn/version "2.0.193"}}
:exec-fn hf.depstar/uberjar
:exec-args {:jar "MyProject.jar"
:group-id "org.example"}}
and assume I have a siimilar alias for :jar
, which also specifies a :group-id
Specifying the same group-id twice is not DRY.
I'm asking is there a way to define a "variable" in deps. edn, and then later when providing a "value" for some key, I can reference the variable?You'd need an alias for :group-id
or whatever you wanted to call it that had {:exec-args {:group-id "org.example"}}
and then you'd specify that alias as well as :uberjar
when building the JAR
If the entire :exec-args
piece would be duplicated (not just :group-id
) then you could put the whole :exec-args
under an alias and under :uberjar
you could say :exec-args :common-args
(or whatever you called that new alias).
But allowing depstar
to treat a keyword argument value as a lookup against other aliases in the project basis would definitely be possible as an enhancement...
The only wrinkle there is that depstar
uses at least some of its :exec-args
to determine how to build the project basis, so it couldn't support some lookups (for exec args that control how to build the basis) because they could only happen after the args had been used.
Does that make sense @dcj?
๐
I'm not sure how well documented that aspect of deps.edn
is. I think Alex has mentioned it on his Inside Clojure blog. I don't know if it's explained in the deps/CLI reference on http://clojure.org
@seancorfield Thank you! I am not sure enhancing depstar to do :keyword val lookup is a great idea, kinda feel like that should be a deps.edn thing, and am not going to bother to propose that. I will try your suggestion to alias the entire exec-args map...
I spent some time attempting to search for exactly this before asking here, and obviously did not find that....
It somewhat cryptically says "Aliases give a name to a data structure that can be used either by the Clojure tool itself or other consumers of deps.edn. They are defined in the :aliases section of the config file." but doesn't give an example as far as I can see.
Thinking about it, it probably ought to resolve such keywords using the runtime basis of depstar
itself since it's about controlling operation of the tool rather than computing the project basis that is used to build the JAR file.
I'll create a GitHub issue and give it some thought. I might ask Alex for his input too.
ok, thanks! what if another tool wants to know the version, for example? seems like this โideaโ is broader than depstar....
It would be nice if this was baked into the CLI itself but I don't think there's a guaranteed generic way to do it that wouldn't step on the toes of some existing tooling. But each individual tool is free to do whatever it wants with aliases.
@dcj I went ahead and implemented that so you can try it out via :git/url
if you want.
:git/url
?
com.github.seancorfield/depstar {:git/url "<https://github.com/seancorfield/depstar>" :sha "a8cf78c9e09e3504e64fc77bcb133a7ada39a68f"}
as your dependency.
Instead of com.github.seancorfield/depstar {:mvn/version "2.0.193"}
OIC ๐
looking at your diffs now
Sorry, I assumed everyone using the CLI and deps.edn
knew about dependencies via :git/url
or :local/root
I just updated the example in the README to use :git/url
so it actually works (even though it's not released yet).
Thank you for doing this! This will be nice.
You can go ahead and use it right now ๐
Yes, I'll try it out soon, worst case, tomorrow.