[Bug 217771] lang/beignet: update to 1.3.1

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217771

--- Comment #10 from Matthew Rezny <rezny at freebsd.org> ---
(In reply to Jan Beich (mail not working) from comment #9)

>libdrm was updated just ~2 months ago. Once 2017Q2 is branched users may find OpenCL 2.0 is auto-disabled during build. Partial upgrades were never supported, so this can be ignored.

Right, people on a quarterly branch with old libdrm won't have the new beignet
with OCL2, people on head will get both new libdrm and new beignet, and anyone
who cares about something like OpenCL is not on quarterly.

>Removing OPENCL20 option makes 1.2 vs. 2.0 troubleshooting harder. Neither beignet port exposes debugging support (vendor optimization gets in the way) nor ports framework provides packages with debugging symbols to help distinguish crash fingerprints from already reported.

Wouldn't two variants, one with 2.0 support and one without, make that exact
issue worse than having a single build would? I must be missing something, it
was my impression that the single build was desirable.

>Not necessarily. GCC switched from C89 to C11 since 5.0 and from C++98 to C++14 since 6.0. Clang switched from C99 to C11 in 3.6 but as of 4.0 is still stuck with C++98.

Ah, good to know, I had not been keeping up on the changes in GCC, and still
bumping into the old default since the default ports gcc is still 4.9

>memalign and aligned_alloc don't have such a restriction. Upstream already uses posix_memalign in other places, so I'm giving up. When pushing files/ upstream some __FreeBSD__ checks would need to be dropped to avoid churn for other BSDs.

I did not mean to cause contention. Using posix_memalign looked to be the more
portable solution is all, and if that is not the case I do welcome to be
corrected as that entails an expansion of knowledge. It sounds like you had a
reason I didn't fully grasp.

>Firefox and Chromium on X11 platforms preserve tabs just fine both via clipboard or primary selection.

This falls into the category of things that didn't work reliably and thus are
no longer tried. Perhaps it depends on the site from which it's copied, some
sites might be converting tabs to spaces before it gets to the browser. 

>> I had previously been advised to use makepatch when adding and changing
>> patches. Is there a more strict set of criteria for when it is appropriate than
>> I am aware of?

>"make makepatch" (like "make makeplist") output isn't supposed to be used as is. It can accidentally merge separate patch files, incorporate sed(1) usage, etc. Porter's Handbook describes noise mainly in relation to "non-functional whitespace changes", so I maybe wrong.

I am aware the output needs to be checked and quite used to doing the dance
with makepatch wherein I copy back all those that were touched in post-patch.
Of course I'm not perfect, I have accidentally committed sed cruft after
regenerating a set of patches so many times I blinded myself to that part. I
have briefly mulled over the idea of another target for this purpose, e.g. make
cleanpatch.

I assume the reason to regularly regenerate patches is to ease fixing hunks
that don't automatically apply after a port update. If the line numbers have
been drifting for a long time and the context is insufficient, it can be
difficult to be sure where to apply that hunk.

>> What is inconsistent about the sorting?
>> lib/beignet/b* < lib/beignet/l*

>See where lib/beignet/beignet.pch is already placed, move *_20.* files there as well.

>lib/beignet/b* < lib/beignet/i* < lib/beignet/l*

Doh! I should have noticed that from your diff. I must have been thinking of
directory first sorting or mentally rewriting lib/beignet/include/ to
include/beignet/ (as it probably should be) when I inserted those.

-- 
You are receiving this mail because:
You are the assignee for the bug.