Cairo is also a dependency now.
/tmp/nix-build-inkscape-0.92.4.drv-0/inkscape-0.92.4/src/display/drawing-context.h:20:10: fatal error: 'cairo.h' file not found
#include <cairo.h>
^~~~~~~~~
1 error generated.
Automated consumers can use 'sed 1d' or similar to remove this header.
This probably makes this output *easier* to consume correctly. Having
this header show up in consumers' terminal or log output is probably not
useful, but hiding it without hiding all error messages would have been
more troublesome that just stripping it from stdout.
I.e., previously, unsophisticated use would show undesired output:
$ some-other-tool
This attribute set contains:
This attribute set contains:
This attribute set contains:
This attribute set contains:
<Actual some-other-tool output>
The simplest way to hide this undesired output would have been
nixos-option ... 2>/dev/null, which would hide all error messages.
We do not wish to encourage that.
Correct use would have been something like:
nixos-option ... 2> >( grep --line-buffered -v 'This attribute set contains:')
After this change, correct use is simpler:
nixos-option ... | sed 1d
or
nixos-option ... | sed '1/This attribute set contains:/d'
if the caller don't know if this invocation of nixos-option will yield
an attribute listing or an option description.
Switch from convention "appease clang-tidy --checks='*'" to
"References are like non-nullptr pointers". The clang-tidy check
"google-runtime-references" complains about non-const reference
arguments, but this is not a convention used in Nix.
Switch from convention "appease clang-tidy --checks='*'" to
"References are like non-nullptr pointers". The clang-tidy check
"google-runtime-references" complains about non-const reference
arguments, but this is not a convention used in Nix.
Switch from convention "appease clang-tidy --checks='*'" to
"References are like non-nullptr pointers". The clang-tidy check
"google-runtime-references" complains about non-const reference
arguments, but this is not a convention used in Nix.
I don't think this matters. As long as one or the other of these is
a std::string, I get an operator== that looks at content rather than
pointer equality. I picked casting the constant over casting the dynamic
thing in hopes that the compiler would have a better chance at optimizing
away any runtime cost.
Deferring to reviewer.
