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