As far as I can tell mingw & cygwin have no need of udev in any form, whether or not its a full on prefix with coreutils and friends or just a straight cross compiler toolchain for mingw-w64. Somehow the virtual/libudev package should have no deps when kernel_Winnt, elibc_Winnt, or elibc_mingw is set.
There are a number of packages that are not required at all on a mingw environment but will be brought in anyways. I believe there is a package.provided that cam be used to circumvent this in your mingw's etc/portage/ environment, as well as something that can be added to profiles that does the same thing. It's worth nothing as well, though, that some packages will want to build against libudev simply because they depend on it in their own code in a non-optional manner.
(In reply to Ian Stakenvicius from comment #1) > There are a number of packages that are not required at all on a mingw > environment but will be brought in anyways. I believe there is a > package.provided that cam be used to circumvent this in your mingw's > etc/portage/ environment, as well as something that can be added to profiles > that does the same thing. > > It's worth nothing as well, though, that some packages will want to build > against libudev simply because they depend on it in their own code in a > non-optional manner. Yes, I'm aware one can package.provide these away (this is the only way I've managed to get as far in improving mingw-w64 stuff on gentoo as I have so far), but in the best situation we shouldn't need individual hacks which will differ from person to person and make actual bug reporting more complicated.
In most cases, virtual/libudev is not pulled into the depgraph unless USE=udev is set on the reverse dependencies. Likely the udev USE flag should be masked in whatever profile(s) are used for mingw. I see no reason to add any USE conditionals to RDEPEND in virtual/libudev.
(In reply to Mike Gilbert from comment #3) > In most cases, virtual/libudev is not pulled into the depgraph unless > USE=udev is set on the reverse dependencies. > > Likely the udev USE flag should be masked in whatever profile(s) are used > for mingw. > > I see no reason to add any USE conditionals to RDEPEND in virtual/libudev. At the moment I don't have access to the machine in question, but I am fairly certain I set USE="-* flags i want and need here" so udev should not be in the mix at all. In addition, the package I'm eyeing for this (media-libs/libsfml) has a hardcoded dep on virtual/libudev:0, so this seems to not be working if that's the case. There is no specific profile for mingw; crossdev sets the embedded profile by default, which needs to be copied in place and edited to be useful.
(In reply to ntzrmtthihu777+gentoo from comment #4) > In addition, the package I'm eyeing for this > (media-libs/libsfml) has a hardcoded dep on virtual/libudev:0, so this seems > to not be working if that's the case. Reading through the build system for media-libs/libsfml, it should only require libudev if the OS is Linux. https://github.com/SFML/SFML/blob/master/src/SFML/Window/CMakeLists.txt#L215 You are not building for Linux. The libsfml ebuild should be adjusted to account for this. You can file a bug to request that the maintainer of the libsfml package make appropriate adjustments.
(In reply to ntzrmtthihu777+gentoo from comment #4) > There is no specific profile for mingw; crossdev sets the embedded profile > by default, which needs to be copied in place and edited to be useful. Lack of a proper profile makes your platform difficult to support in general. There's no way to properly define dependencies if we have no platform-oriented USE flags to work with. You might start building a profile for yourself and others in an overlay. If there is enough demand for it, it could potentially be incorporated into the gentoo repository.
(In reply to Mike Gilbert from comment #5) > (In reply to ntzrmtthihu777+gentoo from comment #4) > > In addition, the package I'm eyeing for this > > (media-libs/libsfml) has a hardcoded dep on virtual/libudev:0, so this seems > > to not be working if that's the case. > > Reading through the build system for media-libs/libsfml, it should only > require libudev if the OS is Linux. > > https://github.com/SFML/SFML/blob/master/src/SFML/Window/CMakeLists.txt#L215 > > You are not building for Linux. The libsfml ebuild should be adjusted to > account for this. You can file a bug to request that the maintainer of the > libsfml package make appropriate adjustments. Apparently libsfml requires a maintainer; I've actually submitted a PR for this issue but wrapping libudev in a use flag is only useful on the windows side of things; building it on linux with the explicit dep for libudev still links against udev anyways. Do you know of a way to only have a use flag exist for a given platform? Or would simply wrapping it in a !elibc_mingw? conditional be enough? In any case, this is thinking too small. We fix libsfml, we fix only that. We fix libudev, we fix anything similar to it that only requires udev on linux/etc.
We are not changing virtual/libudev for this. It's the wrong place for it; any fix needs to be implemented in the packages that (optionally) depend on libudev.
> Or would simply wrapping it in a !elibc_mingw? conditional be enough? I would suggest a dependency like the following for libsfml: kernel_linux? ( virtual/libudev:= )
(In reply to Mike Gilbert from comment #9) > > Or would simply wrapping it in a !elibc_mingw? conditional be enough? > > I would suggest a dependency like the following for libsfml: > > kernel_linux? ( virtual/libudev:= ) I'm not certain, but I believe the BSD build for it may use udev/X as well. Does there exist a sort of umbrella kernel category which would include other *nixy kernels, like bsd and such? something like kernel_posix? or such?
Based on the build system for SFML, udev is only used on Linux. I have never heard of udev being used outside of a Linux environment.
