Page MenuHomeFreeBSD

mail/bincimap: Fix build with Clang 6.0.0
ClosedPublic

Authored by loader on Aug 10 2018, 1:02 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Apr 20, 12:57 PM
Unknown Object (File)
Fri, Apr 19, 2:16 PM
Unknown Object (File)
Fri, Apr 19, 2:16 PM
Unknown Object (File)
Fri, Apr 19, 2:16 PM
Unknown Object (File)
Tue, Apr 16, 6:08 PM
Unknown Object (File)
Feb 15 2024, 2:54 AM
Unknown Object (File)
Feb 15 2024, 2:54 AM
Unknown Object (File)
Feb 15 2024, 2:54 AM
Subscribers

Details

Summary

mail/bincimap failed to build:
https://lists.freebsd.org/pipermail/freebsd-pkg-fallout/Week-of-Mon-20180806/854178.html
https://lists.freebsd.org/pipermail/freebsd-pkg-fallout/Week-of-Mon-20180806/854566.html
https://lists.freebsd.org/pipermail/freebsd-pkg-fallout/Week-of-Mon-20180806/854679.html

Proposed commit log message:

mail/bincimap: Fix build with Clang 6.0.0

Reviewed_by: koobs
Approved by: koobs (mentor)
MFH: 2018Q3
Differential_Revision: D16658
Test Plan
  • portlint: OK (looks fine.)
  • testport: OK (poudriere: 1200075, [armv7, aarch64, amd64], '', tested)

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

koobs edited the summary of this revision. (Show Details)

Merge security updates and all non-version updates to the quarterly branch when/where possible. I've added MFH to the proposed commit log message

This revision is now accepted and ready to land.Aug 10 2018, 10:28 PM
This revision was automatically updated to reflect the committed changes.
head/mail/bincimap/Makefile
6

Why bump PORTREVISION?

head/mail/bincimap/Makefile
6

Sorry, I'm confused, should I bump up PORTREVISION for build fixes that
don't introduce new functionality/behavior change in the generated package?
https://reviews.freebsd.org/D15532#327972

head/mail/bincimap/files/patch-src_greeting.cc
14

Shouldn't it be "v" VERSION " ", with another space added after VERSION?

head/mail/bincimap/Makefile
6

You bump PORTREVISION when there is a package with the same version and the change you introduces changes the new package, so that tools know the package needs to be rebuilt.

It is explained at length in [[ https://www.freebsd.org/doc/en/books/porters-handbook/makefile-naming.html#makefile-portrevision | 5.2.3.1. PORTREVISION ]].

Here, it was not building before, so there was no previous package. Also, for compilers where it was not an error, the change you introduced will not change the compiled file, it is whitespace only.

In the review you quote, I asked a question, on wether or not it was needed, because the changes seemed non trivial, and might change the resulting package. You did not answered the question, you simply bumped PORTREVISION, so I assumed it was needed after all and took it no further.

Language is a very precise tool, if I had said "you need to bump PORTREVISION" then, yes, doing it was right. in the quoted review, I asked if it was needed, so that we'have a discussion, in which you could have told me either "no, it the generated package does not change" or "ah, yes, the package changes".

head/mail/bincimap/files/patch-src_greeting.cc
14

C++11 supports user defined suffix, that's why it needs a space after the string literal:
https://en.cppreference.com/w/cpp/language/user_literal

head/mail/bincimap/Makefile
6

Thanks for clarifying that. Sorry that's my fault, I thought you were suggesting it needs a PORTREVISION bump in D15532.