Skip to content

Add builder for CJOSE #13117

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.

Sign up for GitHub

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

Open
ararslan wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Add builder for CJOSE #13117

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
20564e5
Add builder for CJOSE
ararslan Feb 12, 2026
93b0373
Pkg
ararslan Feb 12, 2026
255a3f8
Inconsequential change to rerun CI
ararslan Feb 12, 2026
354592a
Well that was dumb
ararslan Feb 12, 2026
13289e5
Try autoreconfing
ararslan Feb 12, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 37 additions & 0 deletions C/CJOSE/build_tarballs.jl
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
using BinaryBuilder, Pkg

name = "CJOSE"
# Upstream uses version numbers with 4 components in some but not all cases and it's not
# clear what each component means. For example, v0.6.2 precedes v0.6.2.1 through v0.6.2.4,
# and while some release notes include only security and/or bug fixes, v0.6.2.1 apparently
# also includes new features. So... who knows what anything means.
version = v"0.62.4" # upstream version is 0.6.2.4
Copy link
Member

@fingolfin fingolfin Feb 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So what do you do if they ever go to 0.6.10, or 0.62.0 ?

Maybe unlikely (I don't know the project), but if you do custom versions, might as well go all the way and e.g. do what we do in several other JLLs with similar issues (e.g. for Singular): we multiply some of the parts by 100. So e.g. we might map 1.2.3p4 to something like 1.203.400 (we use .400 instead of .4 because it is handy when one has to make tweaks to the recipe, and if one is using a custom rule for translating the versions anyway.

So here I'd suggest 0.602.400

Of course that'll still break if they increment their version components enough, but the probability is quickly dropping (and you can add more 0s if you consider it a plausible scenario).

Anyway: this is not a blocker, just for your consideration.

Copy link
Member Author

@ararslan ararslan Feb 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I appreciate the suggestion! I figured what I have here is reasonably safe because it looks like their next version will be 1.0 rather than another 0.6. Of course it's not impossible that they'd continue to make 0.6 patch releases (or further 0.x releases) but I figured the probability of a conflict arising in practice with this configuration was vanishingly small. I don't feel strongly though, so if it's better to adopt a pattern that's more consistent with other JLLs, that's fine with me.


sources = [
# NOTE: This is OpenIDC's maintenance fork, not the original Cisco repository
GitSource("https://github.com/openidc/cjose.git",
"8d94c3ad3237ab6a83d2e92fa541542b1b92c023")
]

script = raw"""
cd ${WORKSPACE}/srcdir/cjose
autoreconf -fiv
./configure --prefix=${prefix} --build=${MACHTYPE} --host=${target} --disable-static
make install
"""

platforms = supported_platforms()

products = [
LibraryProduct("libcjose", :libcjose)
]

dependencies = [
Dependency(PackageSpec(name="Jansson_jll", uuid="83cbd138-b029-500a-bd82-26ec0fbaa0df");
compat="2.14.1"),
Dependency(PackageSpec(name="OpenSSL_jll", uuid="458c3c95-2e84-50aa-8efc-19380b2a3a95");
compat="3.0.16")
]

build_tarballs(ARGS, name, version, sources, script, platforms, products, dependencies;
julia_compat="1.6")