pythonPackages.libarcus: use pkgs.protobuf as input

[jokogr]

Motivation for this change

Cura was not building because of libarcus.

Since 5c75318 the protobuf Python module does not have protobuf library as a propagated build input.

This commit makes pkgs.protobuf the input for libarcus, since the latter
searches for the native protobuf library and not for the Python module.

I have tested this by building and running Cura.

/cc @FRidh

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Assured whether relevant documentation is up to date
• Fits CONTRIBUTING.md.

---

[dotlambda]

@GrahamcOfBorg build python3.pkgs.libarcus

[dotlambda]

Please move protobuf from propagatedBuildInputs to buildInputs.

[dotlambda]

This should be backported to staging-19.03.

[jokogr]

@dotlambda If I move protobuf to buildInputs, curaengine still fails as in:

-- Building with Arcus
CMake Error at /nix/store/a4icwnjm9iasay87ggkfp4gw36wsqcpw-cmake-3.13.4/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find Protobuf (missing: Protobuf_INCLUDE_DIR) (Required is at
  least version "3.0.0")
Call Stack (most recent call first):
  /nix/store/a4icwnjm9iasay87ggkfp4gw36wsqcpw-cmake-3.13.4/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)
  /nix/store/a4icwnjm9iasay87ggkfp4gw36wsqcpw-cmake-3.13.4/share/cmake-3.13/Modules/FindProtobuf.cmake:595 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  /nix/store/2dcds8m1xi8x11qxzk4czjcxq6xj6xlc-python3.7-libarcus-3.6.0/lib/cmake/Arcus/ArcusConfig.cmake:31 (find_package)
  CMakeLists.txt:14 (find_package)

Adding protobuf in curaengine's buildInputs explicitly while protobuf is in libarcus' buildInputs also works, are you suggesting doing so?

I think it's more elegant to add just libarcus on packages and the latter to use libarcus CMake library to get protobuf, but we are talking about 2 packages currently relying on libarcus (curaengine and uranium, which is actually used to build cura).

[dotlambda]

Adding protobuf in curaengine's buildInputs explicitly while protobuf is in libarcus' buildInputs also works, are you suggesting doing so?

Yes, definitely.

[delroth]

I think we should instead add back pkgs.protobuf to propagatedNativeBuildInputs for pythonPackages.protobuf. This recent change has broken more than libarcus -- python3Packages.trezor is also broken.

[delroth]

Actually this failure is not fixed with pkgs.protobuf in propagatedNativeBuildInputs -- different root cause from the python3Packages.trezor problem. I'll file a separate PR.

[jokogr]

@delroth as you said, 5c75318 did not fix the problem with libarcus.

@dotlambda I have made the requested changes, could you review and tell me if something more is needed?

[dotlambda]

@GrahamcOfBorg build python2.pkgs.libarcus python3.pkgs.libarcus curaengine