Fork me on GitHub
#depstar
<
2021-03-04
>
markbastian17:03:18

How would I specify the javac options for aot compilation with depstar?

markbastian17:03:39

I am trying to set the target language level of the output.

seancorfield17:03:38

@markbastian Not quite sure what you're asking here: javac is used for compiling Java source code, not Clojure.

markbastian17:03:46

Does’t the aot option defer to javac?

seancorfield17:03:28

AOT is Clojure compilation, not Java compilation.

seancorfield17:03:42

javac is for compiling Java.

seancorfield17:03:39

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.

markbastian17:03:44

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?

mpenet17:03:19

clojure itself is compiled into java8 compatible bytecode

mpenet17:03:25

java8+ that is

seancorfield17:03:37

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

seancorfield17:03:49

The :jvm-opts exec arg was added in depstar 2.0.187 so it's fairly new.

mike_ananev20:03:23

@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

👍 3
mike_ananev20:03:02

to download the template use this command: clojure -X:clj-new :template rssysapp :name myname/myapp01 :snapshot true

seancorfield20:03:59

(assuming you have :clj-new as an alias -- the clj-new README would lead folks to :new instead, as would my dot-clojure repo)

👍 3
dcj21:03:05

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?

seancorfield21:03:33

@dcj I'm not quite understanding what you're asking...

seancorfield21:03:56

An alias can specify :exec-args and when you use that alias, those arguments will be used.

seancorfield21:03:03

(! 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}

seancorfield21:03:19

They merge in alias order.

dcj21:03:22

: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?

seancorfield21:03:53

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

seancorfield21:03:17

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).

seancorfield22:03:14

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

dcj22:03:05

I spent some time attempting to search for exactly this before asking here, and obviously did not find that....

seancorfield22:03:19

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.

seancorfield21:03:15

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...

seancorfield21:03:14

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.

seancorfield21:03:20

Does that make sense @dcj?

dcj22:03:46

@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...

seancorfield22:03:23

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.

seancorfield22:03:49

I'll create a GitHub issue and give it some thought. I might ask Alex for his input too.

dcj22:03:43

ok, thanks! what if another tool wants to know the version, for example? seems like this “idea” is broader than depstar....

seancorfield22:03:39

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.

seancorfield23:03:53

@dcj I went ahead and implemented that so you can try it out via :git/url if you want.

dcj23:03:28

:git/url ?

seancorfield23:03:24

com.github.seancorfield/depstar {:git/url "" :sha "a8cf78c9e09e3504e64fc77bcb133a7ada39a68f"} as your dependency.

seancorfield23:03:36

Instead of com.github.seancorfield/depstar {:mvn/version "2.0.193"}

dcj23:03:44

OIC 🙂

dcj23:03:17

looking at your diffs now

seancorfield23:03:33

Sorry, I assumed everyone using the CLI and deps.edn knew about dependencies via :git/url or :local/root

seancorfield23:03:53

I just updated the example in the README to use :git/url so it actually works (even though it's not released yet).

dcj23:03:01

Thank you for doing this! This will be nice.

seancorfield23:03:27

You can go ahead and use it right now 🙂

dcj23:03:52

Yes, I'll try it out soon, worst case, tomorrow.

3