Opened 12 years ago
Closed 10 years ago
#37212 closed update (duplicate)
json-c: update to 0.10
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | lharple@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | haspatch | Cc: | nonstop.server@…, tresni (Brian Hartvigsen), nerdling (Jeremy Lavergne), mina.macports@… |
Port: | json-c |
Description
json-c has moved to https://github.com/json-c/json-c and needs to be updated to 0.10. The github portgroup should probably be used for this.
Attachments (3)
Change History (19)
comment:1 follow-up: 15 Changed 11 years ago by marka63
Changed 11 years ago by marka63
Attachment: | Portfile-json-c.diff added |
---|
Portfile upgrade from json-c 0.9 to 0.11
comment:3 follow-up: 7 Changed 11 years ago by tresni (Brian Hartvigsen)
My patch retains the old name compatibility for now and gives a variant to remove it so you can see how it will affect your packages. 0.12 will apparently remove the old name completely. The one package I care about (pianobar) seems to be happy either way.
Also properly list out the depends_build requirements and moved to using the github portgroup instead of using weird homepage/master_sites.
Can someone haspatch this? Additionally portfile indicates "nomaintainer"so if someone would review and commit it would be much appreciated.
comment:5 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Keywords: | haspatch added |
---|
We may want to not add the variant. For one thing, negatively-named variants are deprecated.
comment:6 Changed 11 years ago by tresni (Brian Hartvigsen)
Can remove. I just wanted to give port maintainers and users an easy way to see how the upcoming changes might affect them.
comment:7 Changed 11 years ago by nerdling (Jeremy Lavergne)
Cc: | snc@… added |
---|
Replying to brian.andrew@…: Where's the Makefile.in.diff?
comment:8 follow-up: 9 Changed 11 years ago by nerdling (Jeremy Lavergne)
I also added
use_parallel_build no
since the build failed for me until I used build.jobs=1
.
Changed 11 years ago by tresni (Brian Hartvigsen)
Attachment: | Makefile.in.diff added |
---|
comment:9 Changed 11 years ago by tresni (Brian Hartvigsen)
Replying to snc@…:
Actually surprised you got it to build w/o the Makefile.in.diff. I was getting linker errors (unless of course you used the variant in which case it should work fine.) It could be that use_parallel_build no
actually solves the issue I was trying to work around with the Makefile patch. If that's the case, I'd probably prefer going that way then patching. I'll test and submit a new patch (also figure out how to remove the variant or rename to meet the appropriate scheme, newnameonly or something.)
comment:10 follow-up: 11 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
I was thinking the variant could be called "compat".
configure.args --disable-oldname-compat variant compat description {Enable compatibility with old function names} { configure.args-replace --disable-oldname-compat --enable-oldname-compat } default_variants +compat
comment:11 Changed 11 years ago by nerdling (Jeremy Lavergne)
Replying to ryandesign@…:
I'd have the variant off by default since the end game is not having the variant. Right?
If a package needs the names, it can check that the variant is enabled and alert the user. These will need fixed in the end so knowing which ones is helpful.
comment:12 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
I was suggesting the variant be on by default, so that old software that requires old function names will just work for users who want things to just work. Developers who want to discover problems can install it without the variant.
Changed 11 years ago by tresni (Brian Hartvigsen)
Attachment: | json-c_0.11.diff added |
---|
Updated with feedback from snc & ryandesign
comment:13 Changed 11 years ago by tresni (Brian Hartvigsen)
Replying to ryandesign@…
Not sure my vote really matters, but I would agree with ryandesign. I think leaving the variant on for now means that the everything should work as normal but devs can see what (if anything) they need to update.
use_parallel_build no
did resolve the need for the Makefile.in patch so that has been removed.
comment:15 Changed 11 years ago by mina.macports@…
Replying to marka@…:
json-c is now at 0.11.
json-c 0.9 does not support 'json_object_new_int64' where as the newer versions do.
+ 0.11 also allows runtime setting of maximum tree depth, something that was only available as a compile-time #define in previous versions (we had to apply a patch to bump it).
Looking forward to 0.11 hitting macports :)
comment:16 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Superseded by the update to 0.12 submitted in #43781.
json-c is now at 0.11.
json-c 0.9 does not support 'json_object_new_int64' where as the newer versions do.