[Bug 250381] graphics/libosmesa: check-plist fails due to extra files in stage/

[bugzilla-noreply at freebsd.org]

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

--- Comment #9 from John Hein <jcfyecrayz at liamekaens.com> ---
(In reply to Antonio Huete Jimenez from comment #5)
Yes, indeed libOSMesa.so links with libglapi.so.  And graphics/libosmesa
correctly depends on graphics/mesa-libs.  In comment 5, you seem concerned that
libglapi.so (or other files) could be removed, thus breaking
graphics/libosmesa.  That won't happen because of the documented dependency.


(In reply to Antonio Huete Jimenez from comment #8)
You ask why was it (-Dopengl) enabled.  When it was committed (ports r552109),
there was no explanation why it was enabled (nor in the review for that
commit).  Maybe manu@ or zeising@ can weigh in.  But as far as I can tell (on
reading the meson build files and actually building / installing), it does not
need to be enabled for the libosmesa build.

As you pointed it, having 'opengl' enabled triggers an install of gl.h and some
other header files.  Those are already installed by graphics/mesa-libs, so
graphics/libosmesa does not need to enable the installation of those files
itself.  

Additionally, it triggers the build and install of libglapi.so - as described,
mesa-libs already makes libglapi.so available.

In my review, libglapi as built by the graphics/mesa-libs port is correct and
sufficient for the needs of libosmesa.  It is not built any differently by
mesa-libs than it is if -Dopengl=enabled is set for libosmesa build.  In fact,
if it WERE built differently in a material way, then when libosmesa linked with
mesa-lib's version of libglapi.so at run-time, that would be a problem.  So it
is best that graphics/libosmesa links against the version of libglapi.so from
graphics/mesa-libs rather than try to build one itself.

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