-
Notifications
You must be signed in to change notification settings - Fork 841
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
Enable tests whenever possible #815
Conversation
Thanks! |
Hmm, what does this imply for this related discussion? #817 (comment) I'm suggesting that |
It's not to build them, just configure them. This is nothing more than a On Tue, Aug 18, 2015, 11:46 PM Chris Done [email protected] wrote:
|
Configuring them requires building their dependencies, though, right? |
Right, which is why this checks if the dependencies are installed. On Tue, Aug 18, 2015, 11:53 PM Alex R [email protected] wrote:
|
Right, then it ends up the same effect for |
I believe the patch only enables tests/benchmarks if the dependencies are present: it does not automatically build them until |
It does not seem to work for my usecase… So lastly I run You can have a look at the project at tweag/HaskellR
|
As I'm reading it, you're reporting that I'd recommend including |
37c8d14
to
ad93811
Compare
ad93811
to
cb209ae
Compare
…ver-possible Enable tests whenever possible
See #805. Motivation: when you switch between
cabal configure
andcabal configure --enable-tests
, the cabal_macros.h file is changed, leading to the library to be recompiled needlessly. Based on an idea from @gregwebs, this change makes it so that, whenever the test suite and benchmark dependencies are present,--enable-tests
and--enable-benchmarks
are passed in, respectively. We use components as a parameter tocabal build
to control which components are built (unfortunately, there's no way to simply say "don't rebuild the library"...).Pinging @chrisdone and @borsboom. @Fuuzetsu could you test out this branch and let me know if it helps out your
stack build && stack test
use case?