David Craven (2016-08-17 21:14 +0300) wrote:
>> Is it possible to avoid propagating?
>
> Quoting the manual on the section on propagated-inputs:
>
>> For example this is necessary when a C/C++ library needs headers of another
>> library to compile, ...
>
> So the fact that the headers of networkm
> Is it possible to avoid propagating?
Quoting the manual on the section on propagated-inputs:
> For example this is necessary when a C/C++ library needs headers of another
> library to compile, ...
So the fact that the headers of networkmanager-qt include headers from
network-manager, means th
David Craven (2016-08-17 12:34 +0300) wrote:
>> Also there should be a reason for propagating (probably written as a
>> comment). Ideally it should be avoided.
>
> I added comments:
>
> (propagated-inputs
> ; Headers contain #include and
> ;#include
>
> Also there should be a reason for propagating (probably written as a
> comment). Ideally it should be avoided.
I added comments:
(propagated-inputs
; Headers contain #include and
;#include
`(("network-manager" ,network-manager)))
(propagated-inp
David Craven (2016-08-16 21:39 +0300) wrote:
> * gnu/packages/kde-frameworks.scm (networkmanager-qt)
> [propagated-inputs]: Add NETWORK-MANAGER.
> [inputs]: Remove NETWORK-MANAGER.
I would write 'network-manager' instead of NETWORK-MANAGER.
Also there should be a reason for propagating (prob
* gnu/packages/kde-frameworks.scm (networkmanager-qt)
[propagated-inputs]: Add NETWORK-MANAGER.
[inputs]: Remove NETWORK-MANAGER.
---
gnu/packages/kde-frameworks.scm | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gnu/packages/kde-frameworks.scm b/gnu/packages/kde-fram