New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docopt.cpp: init at 0.6.2 #23400
docopt.cpp: init at 0.6.2 #23400
Conversation
rev = "v${version}"; | ||
sha256 = "1rgkc8nsc2zz2lkyai0y68vrd6i6kbq63hm3vdza7ab6ghq0n1dd"; | ||
}; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cmake should be in nativeBuildInputs
|
||
checkPhase = "python ./run_tests"; | ||
|
||
meta = with stdenv.lib; { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no need of writing stdenv.lib in license and platforms when you do meta = with stdenv.lib
a226b00
to
cd6ce89
Compare
@ndowens: Thanks for the review. I removed the stdenv.lib redundancy and made both cmake and python (which is used only for the unit tests) compile time dependencies. |
Oh wait. I get it, python shouldn't be a nativeBuildInput. I'll change that back. |
8c731f7
to
48066ec
Compare
@knedlsepp If python is only used for the tests it should be in nativeBuildInputs. 😄 |
@fpletz: I'm new to cross compiling and confused. When the library is built, it is built in a way that it can be run on some target system. Why do we need the test-dependencies built for the host system? Can the build host even run the cross-compiled tests? |
@fpletz: Could you shed some light on why python belongs into nativeBuildInputs? |
If it isn't needed by the actual program to run and only for build, then it is only a builddep that goes in native
…Sent from my iphone
On Mar 8, 2017, 11:12 AM -0600, Josef Kemetmüller ***@***.***>, wrote:
@fpletz (https://github.com/fpletz): Could you shed some light on why python belongs into nativeBuildInputs?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (#23400 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/AAHL7xTbY68IzCixrBzjWPFjuesYvfS0ks5rjuGRgaJpZM4MRVSd).
|
Well it is actually used to run it, but only during the checkPhase, so it's not perfectly obvious to me. |
What about the build error https://travis-ci.org/NixOS/nixpkgs/jobs/207280770 |
@joachifm: Oh. Thanks for pointing that out! |
48066ec
to
7f663a2
Compare
@joachifm: I forced an LD_LIBRARY_PATH during the checkPhase, so the unit test binaries can properly find the library. What's your opinion on the native v. non-native issue? |
Putting python in I agree with your point that if code generated for the host cannot run on the build machine, then the build machine cannot perform tests that involve executing said code, without some sort of compatibility mechanism. As far as Hydra is concerned, I think it's always the case that build=host (at least such that host code can run on build). |
Ok. Thanks for your clarifications. I added python to the nativeBuildInputs. |
7f663a2
to
ed7a1ac
Compare
Motivation for this change
docopt.cpp is an awesome alternative to Boost.Program_options.
Things done
(nix.useSandbox on NixOS,
or option
build-use-sandbox
innix.conf
on non-NixOS)
nix-shell -p nox --run "nox-review wip"
./result/bin/
)