In app-emulation/open-vm-tools, the 'xinerama' use flag is mapped to the --disable-multimon option and, as far as i'm aware (but I have not directly tested this), will correctly make a build not requiring any part of the xinerama libraries. However, the new unity feature (as of 2008.08.08-109361 and in newer versions as well) requires xinerama to build correctly, and the flags do not indicate this, resulting in a build failure if the 'unity' flag is set and xinerama is not available. I reported this upstream (https://sourceforge.net/tracker/index.php?func=detail&aid=2301228&group_id=204462&atid=989708), and was informed that unity does require xinerama to be available and is not intended to be influenced by the --disable-multimon option. The solution here is to add a dependency requiring xinerama when the 'unity' flag is enabled. Reproducible: Always Steps to Reproduce: 1. Attempt to build app-emulation/open-vm-tools with USE="unity" and no xinerama libraries available. 2. Build will fail at lib/unity/unityPlatformX11.c
Thanks, I'm not sure that's the best solution, since people who set -xinerama +unity might wonder why xinerama's needed. I'll probably add a check to ensure that unity is never on when xinerama is off, and give a warning message otherwise...
I'm not sure a warning is quite right either - with unity enabled and xinerama unavailable, the build *will* fail to compile, or use xinerama anyway if those files happen to be available. I agree that it could be confusing to have xinerama pulled in with the xinerama flag unset, though. I think either solution would probably be acceptable, if there aren't any other applicable options.
Ok, the ebuild now dies with an error if USE="unity -xinerama". Without the error, the latest upstream would simply turn off unity support (they fixed it, so it won't fail to compile anymore). Either way, it would confuse a fair number of people, so I went with the error...
