1 |
On 16/10/15 03:04, Michał Górny wrote: |
2 |
> |
3 |
> |
4 |
> Dnia 15 października 2015 17:44:47 CEST, Michael Palimaka <kensington@g.o> napisał(a): |
5 |
>> This could happen if ninja is manually enabled (eg. make.conf) but not |
6 |
>> installed |
7 |
>> --- |
8 |
>> eclass/cmake-utils.eclass | 5 +++++ |
9 |
>> 1 file changed, 5 insertions(+) |
10 |
>> |
11 |
>> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass |
12 |
>> index 480cd09..012b13f 100644 |
13 |
>> --- a/eclass/cmake-utils.eclass |
14 |
>> +++ b/eclass/cmake-utils.eclass |
15 |
>> @@ -228,6 +228,11 @@ _generator_to_use() { |
16 |
>> |
17 |
>> case ${CMAKE_MAKEFILE_GENERATOR} in |
18 |
>> ninja) |
19 |
>> + # if ninja is enabled but not installed, the build could fail |
20 |
>> + # this could happen if ninja is manually enabled (eg. make.conf) |
21 |
>> but not installed |
22 |
>> + if ! has_version dev-util/ninja; then |
23 |
> |
24 |
> I'd suggest avoiding has_version and just checking for the binary. type -P, I think. Ciaran can give you the rationale, I believe. |
25 |
|
26 |
There's no guarantee that the binary will be provided by dev-util/ninja |
27 |
(we've had a bug about this already). |