Created attachment 166593 [details] Patch for devel/capstone. Proposed patches add a new port for capstone4 and set PKGNAMESUFFIX to 3 for existing devel/capstone to distinguish it from another major version. Despite the fact that capstone4 is still not the final stable release devel/radare2 (which is already in ports tree) is using capstone v4. According to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205862 we'd like to make radare2 build use system's capstone and not declare a conflict on capstone. Attaching build logs for ports and dependents of devel/capstone.
Created attachment 166594 [details] New port devel/capstone4
Created attachment 166595 [details] devel/capstone build log for 9.3-amd64
Created attachment 166596 [details] devel/capstone build log for 10.2-amd64
Created attachment 166597 [details] devel/capstone4 build log for 9.3-amd64
Created attachment 166598 [details] devel/capstone4 build log for 10.2-amd64
Created attachment 166599 [details] devel/py-capstone build log for 9.3-amd64
Created attachment 166600 [details] devel/py-capstone build log for 10.2-amd64
Would you mind if we moved capstone to capstone3 ? The dependend port list is limited to devel/py-capstone, so if we fix that dependency as well...
(In reply to Kurt Jaeger from comment #8) I don't have any objections. The reason i went this way is I was thinking about devel/capstone tracking latest stable version. devel/capstone4 is sort of an exception (workaround) as it not stable yet, however, already in use. I guess our options are: 1) devel/capstone tracks stable releases (v3 for now), devel/capstone4 becomes essentially devel/capstone-devel or 2) rename devel/capstone to devel/capstone3, keep devel/capstone4 and then keep adding new ports for any new major version. Option 1 is easier on porter's side, however, looking at capstone project they actually have various development branches which drastically differ, so not clear which one to track. Option 2 provides more variety to users and some flexibility to port maintainers in case there are some outdated ports that use (or will use) capstone. And actually nothing stops having devel/capstone in this case too. Option 2 seems better to me now.
(In reply to oleksii.tsai from comment #9) I think I already confirmed by mail that 2) is preferred 8-) I'm a bit busy right now, will get back to this ticket later. Or someone else beats me to it 8-)
A commit references this bug: Author: pi Date: Sun Jul 10 12:57:27 UTC 2016 New revision: 418316 URL: https://svnweb.freebsd.org/changeset/ports/418316 Log: devel/capstone: move to capstone3, introduce capstone4 - update py-capstone to use capstone3 PR: 206941 Submitted by: oleksii.tsai@gmail.com Approved by: oliver.pntr@gmail.com (maintainer timeout) Changes: head/MOVED head/devel/Makefile head/devel/capstone/ head/devel/capstone3/ head/devel/capstone3/Makefile head/devel/capstone4/ head/devel/capstone4/Makefile head/devel/capstone4/distinfo head/devel/capstone4/pkg-plist head/devel/py-capstone/Makefile
Committed, thanks! Uff, this took too long 8-(