Also add a patch to remove the need of USE_GCC=yes.
Details
Diff Detail
- Repository
- rP FreeBSD ports repository
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 31277 Build 28918: arc lint + arc unit
Event Timeline
Looks fine to me.
Personally I'd add a note at the beginning of files/patch-src_biblesync.cc that explains why you are doing this (and that it allows compilation with clang over just GCC).
Are there any dependent ports that would require bumping PORTREVISION due to the change of the libbiblesync.so version?
I did not even knew that we could add comments to patches: thanks mentor :)
I added a comment: can you please check the file again to confirm that I did it properly, since it is the first time? Thanks!
I have to bump PORTREVISION for misc/xiphos, although this will soon be updated as well. Xiphos had USE_GCC set as a side effect of having biblesync built with gcc, so this could probably be removed, but I will check it when I actually update xiphos: it has some heavy dependencies, so testing needs some time.
On second thought, I must ensure that xiphos still compiles with the updated biblesync. So I need to test it before I commit this update.
Thus I propose to also remove USE_GCC from xiphos now instead of when I will update it.
You're welcome!
I dug out some examples to demonstrate how I have been using this:
- svn diff -c 524678 $PORTSDIR/emulators/wine/files/ # look for those files that got removed and their comments at the top
- lang/gcc9/files/patch-gfortran-libgcc # super long, but super important
- emulators/wine-devel/files/patch-dlls_kernel32_Makefile.in emulators/wine-devel/files/patch-libs-wine-mmap.c lang/gcc9/files/patch-clang-vec_step lang/gcc9/files/patch-gets-no-more for some further ones.
Yes, your change looks good. Personally I'd add an empty line between the note and the patch, but that's subjective.
What I find useful is how to handle this with version updates and note whether the patch comes from upstream, you submitted it upstream, there is an upstream bug report (and a reference if possible). Makes life so much easier down the road. ;)
Yes, and yes.
Please make sure the commit message explains what's going on (when viewed from the context of either affect port).