On Sat, Oct 17, 2015 at 10:37 AM, Michał Górny <mgo...@gentoo.org> wrote:
> On Fri, 16 Oct 2015 03:22:48 +1100
> Michael Palimaka <kensing...@gentoo.org> wrote:
>
>> On 16/10/15 03:04, Michał Górny wrote:
>> >
>> >
>> > Dnia 15 października 2015 17:44:47 CEST, Michael Palimaka
>> > <kensing...@gentoo.org> napisał(a):
>> >> This could happen if ninja is manually enabled (eg. make.conf) but not
>> >> installed
>> >> ---
>> >> eclass/cmake-utils.eclass | 5 +++++
>> >> 1 file changed, 5 insertions(+)
>> >>
>> >> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
>> >> index 480cd09..012b13f 100644
>> >> --- a/eclass/cmake-utils.eclass
>> >> +++ b/eclass/cmake-utils.eclass
>> >> @@ -228,6 +228,11 @@ _generator_to_use() {
>> >>
>> >> case ${CMAKE_MAKEFILE_GENERATOR} in
>> >> ninja)
>> >> + # if ninja is enabled but not installed, the build
>> >> could fail
>> >> + # this could happen if ninja is manually enabled (eg.
>> >> make.conf)
>> >> but not installed
>> >> + if ! has_version dev-util/ninja; then
>> >
>> > I'd suggest avoiding has_version and just checking for the binary. type
>> > -P, I think. Ciaran can give you the rationale, I believe.
>>
>> There's no guarantee that the binary will be provided by dev-util/ninja
>> (we've had a bug about this already).
>
> Excuse me but did you agree with me, then commit the old version anyway?
I didn't seem like he agreed with you. He explained that checking for
a binary named ninja isn't sufficient because some versions of
net-irc/ninja install a 'ninja' binary. See bug
https://bugs.gentoo.org/show_bug.cgi?id=436804
