[Bug 217016] graphics/libGL: update to 17.0.1 to get llvm40 support

[bugzilla-noreply at freebsd.org]

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

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

> Detecting dependencies at runtime is undesired.

I was thinking of this akin to selecting the correct compiler and trying to
accommodate the original request, but if we are looking at it in terms of
dependency handling then it should just be a one line patch to change
MESA_LLVM_VER=39 to MESA_LLVM_VER?=39.

>I wanted the knob hidden, so it can allow footshooting. Not really a feature >supported by the maintainer.

If someone really wants to shoot their foot off, they can relax or drop the
version checks entirely, but the maintainers need not invite accidental foot
shooting with an a relaxed version requirement.

>[[:graph:]]* wasn't dropped but plain incorrect. According to re_format(7) >negating character class is perfectly fine but BSD regex doesn't support >shorthand variants. This may change with the import of libtre in future.

>I do use CPUTYPE?=native in make.conf myself, so this was tested.

That was what was suggested to me and it worked so I did not scrutinize it. I
saw it disappear with no explanation given so it appeared to have been dropped.
Thank you for stating the reason. I guess it should have been [:space:] instead
of [:graph:] in the replacement

>17.0.1 requires more extensive changes. I've tried to use the syntax compatible >with both GNU sed and BSD sed. files/configure.ac was out of date, so it should >either be removed or submitted upstream. Leaving it as is is confusing.

Now that you explain that, it makes more sense. I was evaluating the proposed
patch from the point of view of the original request, what is the minimum
change to accomplish that. The patch had a lot more going on, and at glance and
without any statement as to why those changes were made, it looked like
post-patch bleed into makepatch again. I was not wanting to patch configure.ac
to avoid an otherwise unnecessary autoreconf, but if we can patch the .ac and
upstream that then it certainly makes sense to do so.

>What else? For one, the following change was made to be consistent with the >rest of the file.

No problem with the style change there, and there wasn't necessarily anything
wrong with the parts I didn't mention, just that I did not compare them to my
Mesa 17 WIP after tripping over the sed changes. Perhaps incorrect wasn't the
right label, it was more of unexplained changes that looked incorrect on the
surface.

(In reply to Jan Beich (mail not working) from comment #10)

>If you didn't notice my changes in files/configure.ac are ready to be submited >upstream (support both GNU and BSD sed). It's just getting involved with >upstream review is a bit too time-consuming for me. I'm already exhausted with >upstreaming stuff in Firefox.

No, I didn't notice, but now that you state the purpose, I thank you for doing
so. I plan to upstream as much as possible once I have us on 17.0.x, Emil
recently contacted us requesting we send up what we have. I just have to ask,
if the patched configure script works with BSD and GNU sed, do we still need
the bit for DragonFly in post-patch?


I intend to restructure the Mesa ports during the update to 17. It does not
make sense to have libGL as the master, and it might not make sense to still
have a separate libGL. In order to enable Wayland support for libEGL without
ending up with Mesa always depending on part of Wayland requires adding an
option, but same option would need to be present in gbm and setting the option
differently there would resulting in a broken system. The simplest solution to
guarantee consistency is to make gbm part of libEGL. I only found one port that
requires gbm but not libEGL, so the combination should be inconsequential. Of
course, doing that, I can't help but think how much simpler it would be to have
libGL, libEGL (with gbm), libglesv2, and libglapi in a single mesa-libs port
which any (E)GL(ES) user would depend on. The only separate parts would be
mesa-drivers aka dri, clover, and osmesa. Most consumers depend on libGL, which
is the majority of the size and already would pull in libglapi and gbm with it.
Adding in libEGL and libglesv2 is an increase from ~2MB to 3MB installed, so
harmless and hardly worth separating the libs into numerous ports/packages that
require rebuilding some parts several times and complicate options. Maybe I
should make a meta-port simply called mesa to serve as the master and
optionally depend on the rest. Input on the idea is welcome.

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