| Summary: | media-libs/glfw should depend on X11 packages only for UNIX systems (non-WIN32 & non-APPLE) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | tschwinger |
| Component: | Current packages | Assignee: | Gentoo Games <games> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | prefix, tschwinger, vapier |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Have dependencies depend on the X USE-flag and set it by default
Revised patch Patched ebuild |
||
|
Description
tschwinger
2015-02-12 00:37:05 UTC
Created attachment 396222 [details, diff]
Have dependencies depend on the X USE-flag and set it by default
CC to apparent ebuild maintainer Just changing deps without changing something in src_configure is almost always a sign that something's wrong. In this case, even with USE="-X" the library is built against the X11 stuff if it's available which is not allowed since it makes the dep automagical. Further patching of the build scripts is necessary if you want to be able to make X optional. I suggest coordinating with upstream to make the build scripts support what you're trying to do. Upstream build script does certainly support it. We're talking about a cross platform library: The dependency is the only reason why you can't cross-compile to library to native Windows or embedded targets (in these cases running on platform default libs or EGL, respectively). In order for the patch to the ebuild to be ok it would have to result in a package that didn't depend on X when built with USE="-X", even if X is installed. That's not what happens. If I apply your patch and build the package with USE="-X" the build system finds that X is installed and builds against it resulting in an implicit dependency. OK, this time it's easier to understand. I had figured that out rereading your earlier post - excuse my too quick reply. It appears the libarary actually does have a hard dependency on X11 on UNIX. So all that's left to do is to detect whether we're cross-compiling to Windows or OSX for now. There should be USE-flags (at least for Windows) somewhere. Searching... maybe someone from toolchain has tips Could say
!x86-winnt? ( !x64-winnt? ( !x86-macos? ( !x64-macos? ( <X-libs> ) ) ) )
but it looks awkward and maybe there's a nicer way of expressing the same thing.
Also 'x64-winnt' appears to be missing in /usr/portage/profiles/arch.list, so I had to add it in IUSE as a workaround (I have such a profile in my local overlay, but its 'arch.list' apparently gets ignored).
yes, the cmake logic is a bit of a mess -- look for the "Detect and select backend APIs" section arch lists isn't the way to go. the kernel_xxx or elibc_xxx flags are probably the closest you'd get, but even that isn't terribly accurate. the prefix team might have a better suggestion as to what they've been using in cases like this. Adding
REQUIRED_USE="!elibc_Winnt? ( !kernel_Darwin? ( X ) )"
to the original patch should do the trick, no?
Grepping over /usr/portage shows that the common way of detecting those platforms is oddly inconsistent. In particular there are no matches for 'kernel_Winnt', which would seem the more appropriate way of expressing a dependency on the platform.
Actually I would expect seeing things like elibc_msvcrt and elibc_mingw (and someone may know another libc that works on Windows) by common sense.
I remember seeing 'kernel_Winnt' before, somewhere. Also it's in my overlay profile, which is based on 'prefix' in a state of several months ago and I can't remember inventing it...
Did it get removed? Is it another issue? Anyone have a clue?
No. OSX/Windows platforms won't respect 'X' USE-flag then. I'm learning :)
$(cmake-utils_use !X _GLFW_COCOA=no _GLFW_NSGL=no
_GLFW_WIN32=no _GLFW_WGL=no
_GLFW_X11=yes _GLFW_GLX=yes)
Just kidding.
Created attachment 396442 [details, diff]
Revised patch
Created attachment 396444 [details]
Patched ebuild
The patch optimistically contains 'kernel_Winnt'. Would be great if someone could shed some light on its status - else just s/kernel_W/elibc_W/. Also notified upstream for the Cmake side of the story. There should ideally be choice options to select APIs for windowing and graphics that will override the auto detection. prefix happy with the latest patch or is there a better way? As Cygwin (at least in theory, not sure about practice, nor about our preference yet) does support both X11 and Win32-UI, question is whether glfw takes Cygwin as Unix or Win32. This also feels related to https://archives.gentoo.org/gentoo-dev/message/e222873710c46643fb2a925b7f8362eb I can imagine something like: IUSE="... aqua w32ui +X" RDEPEND="... X? ( x11-libs/libX... )" REQUIRED_USE="^^ ( aqua w32ui X )" Agreed the build system should be forced to either use the selected UI, or yell about the selected UI to be unsupported. But as Cygwin is in very early state still, I do not really care yet. we really shouldn't be doing this, it's too much lying and cheating, sorry |
