Whenever using make for this port, there is the warning:
make: "/usr/ports/www/chromium/Makefile" line 210: warning: "/usr/bin/grep mempcpy /usr/include/string.h" returned non-zero status
There is no mempcpy in string.h (13.0-RELEASE-p4).
This warning is unnecessary and possibly misleading.
Created attachment 227679 [details]
(In reply to Geezer from comment #0)
> There is no mempcpy in string.h (13.0-RELEASE-p4).
That's the point, the port needs to know that. There is one in more recent -CURRENT versions and it can't be tested via OSRELEASE.
But this test isn't optimal: It's executed every time the Makefile is evaluated *and* make prints a warning when it fails.
Find attached a possible patch to solve both issues (at the cost of being hard to read, unfortunately).
Created attachment 227685 [details]
As a possibly better alternative, here's a patch using OSVERSION instead of an explicit check with grep. This might be wrong for -CURRENT built during a short period of time (2 days?), but is readable and doesn't have any of the negative effects.
Yup. A lot simpler.
(In reply to Felix Palmen from comment #3
NEVER DO IT UNTIL CORRESPONDING BUMP ON BASE IS DONE, please!
The problematic commit on base doesn't have corresponding bump.
This kind of change SHALL make future confusion.
And the fix is already proposed on Bug257352 by Tatsuki Makino. 
(Not an attachment, though.)
If the earlier patch here (I've not testet, though) works fine,
it is also OK.
(In reply to Tomoaki AOKI from comment #5)
> NEVER DO IT UNTIL CORRESPONDING BUMP ON BASE IS DONE, please!
> The problematic commit on base doesn't have corresponding bump.
> This kind of change SHALL make future confusion.
The only reason I could see *not* to resort to OSVERSION would be if the patch would actually break something when strpcpy() is present in base. Even then, I wonder whether it's worthwhile to have such an ugly hack in place just for a period of 2 days when base had a commit without an OSVERSION bump… but then, it won't be me to decide, I suggested two approaches for a reason.
> And the fix is already proposed on Bug257352 by Tatsuki Makino.
This fix over there has the drawback that the grep is still executed every time the Makefile is evaluated (instead of only on expansion of EXTRA_PATCHES). Unfortunately, I think there's no really readable solution to fix this, you'd have to live with what I suggested above.
Created attachment 227730 [details]
Because of the readability issue, I updated my suggestion w/o OSVERSION to include a comment explaining the "what" and "why that way".
(In reply to Tomoaki AOKI from comment #5)
I'm not sure what you are missing. We have checked when this change was done in base and the first OSVERSION bump after this change was two days later and is the one found in the patch. So only if someone built an OS in the two days between the commit and the OSVERSION bump the check would be wrong and then in the harmless direction, i.e. not using mempcpy when it is available.
What's wrong with doing it that way? It is sufficiently accurate, idiomatic (see §4.4 porter's handbook), fixes the warning, and improves performance.
They're not going to bump OSVERSION for every single commit, so I'm not sure what you are looking for.
(In reply to Felix Palmen from comment #7)
Thanks! Worked fine for me.
Tried `make DISABLE_VULNERABILITIES=yes extract patch` on stable/13 and main having mempcpy() and extra-patch was gracefully ignored.
Tried above, but modifying word mempcpy to nonexistent mempcpie made extra-patch applied properly. (To simulate base revs NOT having mempcpy().)
*Not actually built as it requires a plenty of time.
(In reply to Robert Clausecker from comment #8)
Why I'm hesitating to use regular OSVERSION way here is because no commit for version bump mentions about mempcpy() addition.
This can make confusion tracking changes in the future.
Single bump for multiple commits is NOT AT ALL a problem, if the commit message lists all targetted commits, regardless they're related each other or not.
If I'm not missing something, no bump mentions the commits adding mempcpy().
And for this case, checking for mempcpy() instead of checking for OSVERSION has an advantage that no more update is needed when mempcpy() is added to branches that doesn't have it currently.
www/chromium is a huge port and changes without actual update would be better minimized, I think.
Anyway, Felix's latest patch looks fine enough for me.
Thanks again, Felix!
(In reply to Tomoaki AOKI from comment #10)
Well, thanks for the explanation, so I now get you just worry about sane traceability. This, of course, makes sense!
I still think using grep is an ugly hack (and I hope I found the least troublesome version of it now, hehe) and relying on OSVERSION would be much better. Maybe this would warrant a PR against base to "fix" this with the next commit that bumps OSVERSION?
(In reply to Felix Palmen from comment #11)
But one thing to mention.
If swiching to OSVERSION way, and the addition of mempcpy() is planned to be MFC'ed to stable/12 and stable/11, this port should be required to updated again, while (ugly) grep hack doesn't need it.
I wonder which way would be better for this huge port.
(In reply to Tomoaki AOKI from comment #12)
> If swiching to OSVERSION way, and the addition of mempcpy() is planned to be
> MFC'ed to stable/12 and stable/11, this port should be required to updated
> again, while (ugly) grep hack doesn't need it.
I see the point; in fact, if this change already hit stable/13, my OSVERSION based patch is already wrong :( -- but…
> I wonder which way would be better for this huge port.
I still think it's the better approach cause calling external tools should be avoided. These things could pile up and kill any make performance. At the very least, make sure to do these calls only when really required to expand the variable in question (which is what my patch does).
Of course, just an opinion so far. IMHO, go with the "fixed" grep for now, but revisit this once OSVERSION bumps refer the change in question.
Much as I appreciate all the help and support on this PR, in many ways the nature of the patch is irrelevant.
If when mempcpy is available, then there is no warning, and when mempcpy is not available, the warning is suppressed, then logically that warning is absolutely redundant.
Should the warning merely be removed?
(In reply to Geezer from comment #14)
This is not about a warning, but about inclusion/exclusion of an extra patch, depending on the availability of mempcpy(). You can't remove that, it's required for correct operation. The warning was an unfortunate by-product. I'm now just waiting for someone to commit e.g. my suggested fix (silence the warning *and* make sure the test only executes when really needed) in the (v2) patch…
(In reply to Felix Palmen from comment #13)
Looks rasonable to me. Thanks!
BTW, stable/13 already has mempcpy() MFC'ed, while stable/12 and 11 have not.
So this would be better revisited when MFC'ed to stable/12 AND stable/11,
or made clear that not at all further MFC is planned.
(In reply to Tomoaki AOKI from comment #16)
11.4 is the final release from stable/11, so I don't see any more MFCs there ;)
But apart from that, agreed.