-
-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] Replace depstar with tools.build in template #80
Comments
I was wondering if there has been any progress on this. The uberjar creation using depstar was fine until I tried to bump This builds: This fails uberjar creation:
Content of the report:
|
No progress so far. However, you are lucky since I finally have some energy to donate my time to OSS. Expect a fix today/tomorrow. All the best to you Chris! |
Thank you, Karol - glad to hear the energy levels have improved! Let me know if I can help with any testing. |
@FieryCod I've tested this locally. The generated project using the template, compiles fine. And when upgrading the tick dependency in my project from It wasn't a straight upgrade, however. When transferring to my project, the basic process was simple enough but I had to make changes to the GraalVM native build config to ultimately get this to work. Before changing any of the deps, I tried the new build with my project, but it failed with the following:
Adding The Lambda executes successfully. However, the Lamdba package size has increased by 0.5 MiB: Was 24.5 MiB, now 25 MiB. The GraalVM compiled output has increased by almost 3MiB, and the GraalVM builds have slowed by 10s. Minor observation - I updated the location of the generated target directory to put it under |
Comparing GraalVM output between depstar and tools.build, the number of reachable fields has increased significantly between the two compile runs, and GraalVM depstar:
GraalVM tools.build:
|
As a very coarse comparison between the content of the respective uber jars reveals some differences:
|
I'm going to roll this out to a few other lambda projects. I suspect the increase in code size is from |
I've applied the new build to another 6 Lambda functions and the package size inflation is negligible: 0 - 0.1MiB |
Could you share the repro? I would love to take the look into the generated bytecode and compare it side by side (tools.build vs depstar). Maybe it would be something worth reporting upstream to The single-segment warnings are something you should address rather than add the init options as you did. |
Not sure how I'd do that.
|
The depstar version had the following, which I can't see an alternative for in the new version. Could there be anything in that?
|
In another Lambda, I had a namespace amongst my lambda code called The code is not referenced from the Lambda code. With depstar, it was always ignored. With |
I just added the original
This makes sense after reading this section at clj-easy |
Depstar is deprecated and should be replaced with the
tools.build
script.The text was updated successfully, but these errors were encountered: