Date: Fri, 10 Mar 2017 01:24:03 +0000 From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: [Bug 217016] graphics/libGL: update to 17.0.1 to get llvm40 support Message-ID: <bug-217016-7141-TOhAMAg2wB@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-217016-7141@https.bugs.freebsd.org/bugzilla/> References: <bug-217016-7141@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217016 --- Comment #11 from Matthew Rezny <rezny@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=3D39 to MESA_LLVM_VER?=3D39. >I wanted the knob hidden, so it can allow footshooting. Not really a featu= re >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?=3Dnative 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 drop= ped. Thank you for stating the reason. I guess it should have been [:space:] ins= tead of [:graph:] in the replacement >17.0.1 requires more extensive changes. I've tried to use the syntax compa= tible >with both GNU sed and BSD sed. files/configure.ac was out of date, s= o it should >either be removed or submitted upstream. Leaving it as is is c= onfusing. Now that you explain that, it makes more sense. I was evaluating the propos= ed 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 a= nd upstream that then it certainly makes sense to do so. >What else? For one, the following change was made to be consistent with th= e >rest of the file. No problem with the style change there, and there wasn't necessarily anythi= ng 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 t= he 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 subm= ited >upstream (support both GNU and BSD sed). It's just getting involved w= ith >upstream review is a bit too time-consuming for me. I'm already exhaus= ted with >upstreaming stuff in Firefox. No, I didn't notice, but now that you state the purpose, I thank you for do= ing 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 as= k, 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 opt= ion 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, w= hich 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-217016-7141-TOhAMAg2wB>