Use rattler-build

[bollwyvl]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

References:

• for Investigate transitioning to a v1 recipe.yaml? #183

Notes:

• have already started with outputs to see if there are gremlins, might need an explicit script: file: build
• there are probably some better templating patterns
• not sure if the license thing is going to work

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe/recipe.yaml) and found some lint.

Here's what I've got...

For recipe/recipe.yaml:

• ❌ The top level meta keys are in an unexpected order. Expecting ['schema_version', 'context', 'recipe', 'source', 'build', 'outputs', 'about', 'extra'].
• ❌ This recipe is using a compiler, which now requires adding a build dependence on ${{ stdlib("c") }} as well. Note that this rule applies to each output of the recipe using a compiler. For further details, please see META: {{ stdlib("c") }} migration conda-forge.github.io#2102.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/13226460870. Examine the logs at this URL for more detail.}

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/recipe.yaml, recipe/meta.yaml) and found it was in an excellent condition.

[bollwyvl]

Welp, getting a linux build isn't too shabby for a first cut. I'll dig through the logs a bit... i wonder if conda-build was doing some magic unpacking on osx...

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml, recipe/recipe.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ Jinja2 variable references are suggested to take a ${{<one space><variable name><one space>}} form. See lines [19].

For recipe/recipe.yaml:

• ℹ️ Jinja2 variable references are suggested to take a ${{<one space><variable name><one space>}} form. See lines [19].

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/13228689707. Examine the logs at this URL for more detail.}

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/recipe.yaml) and found it was in an excellent condition.

[bollwyvl]

Welp, this is basically building now: not sure what further tricks might be able to be pulled to claw back some disk during the linux-aarch64 build...

[h-vetinari]

not sure what further tricks might be able to be pulled to claw back some disk during the linux-aarch64 build...

You can add

azure:
  free_disk_space: true

to conda-forge.yml and rerender

[bollwyvl]

I promise not to poke it any more until it builds 🤞 actually, unlikely to do any further conda-forge things today, so if there is anything glaring, please do jump in!

[bollwyvl]

After this operation, 1239 MB disk space will be freed.

Love to see that.

[bollwyvl]

Yeah, looks like it worked, and had the desired net effect:

• main
• this pr

This is likely reviewable as-is, though would feel better if i had also turned on artifact uploading, and someone could shake it down on some non-x86_64 boxen.

I guess the next step (likely not on this PR, but could be, I guess) would be to see if we can split the JRE bits into their own package. Looking again at, for example, debian's jre and jdk, it's not immediately obvious how one might make that call (e.g. everything in lib), but really don't want to double the build time... and would need some plan for redistributions.

[bollwyvl]

One thing in perusing various other packagings: arch adds some more build flags:

  if check_option "lto" "y"; then
    jvm_features="zgc,shenandoahgc,link-time-opt"
  else
    jvm_features="zgc,shenandoahgc"
  fi

  bash configure \
    --with-jvm-features="${jvm_features}" \

Browsing through failure modes related to this, it sounds like the biggest threat is it being slow and using more memory, but otherwise, if we're doing source builds...

[h-vetinari]

but really don't want to double the build time...

I don't mind the builds here taking longer as long as it provides a net benefit for users

and would need some plan for redistributions.

Let's please move that part of the conversation to #152 - if you can lay out the concerns and how we might address them, that would be useful!

[bollwyvl]

Welp, looking at #185, I don't see how we're going to get #152 without --experimental/cache