-
Notifications
You must be signed in to change notification settings - Fork 702
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
new-build
returns exit code 1 (but doesn't indicate that it fails) when run in a cabal project
#5974
Comments
does |
Here is the output of
Here are the contents of
|
seems similar to #5641 |
@RyanGlScott the possibly related #5461 is closed and maybe your issue was corrected by the same fix, could you confirm if the problem still is reproduced? |
The problem still persists as of commit cdd8d97. |
Perhaps there is some low-hanging fruit here? #6102 fixes something like that for |
BTW, I think this is really quite important. I'm so used to just running with -j1 whenever I want to see an error, that I easily forget how off-putting this is to newcomers and also that -j1 is not a common wisdom any more. |
And
To me, this says that |
It does say that though:
|
I mean the default used if no |
@WolframKahl: that default comes from your
|
It's worth considering if we should say somewhere in the |
Perhaps something along the following lines?
And also change
to something like:
(This is how I eventually found this issue, by having broken links in the |
This issue, and the issues I traversed before getting here, are at least three years old. So it must be a feature, and is worth documenting as such. |
Oh, great, thanks. This is a good start. I think many (most? all?) commandline options override config file. Do we say so for all? Only in Also, the same help for options is displayed for all (?) cabal commands, of which It would indeed be good to display the default value, but I have no idea how hard it is. E.g., how many other sources are taken into account and in what order, e.g., env vars, config, cabal.project, cabal.project.local, etc. This may be a complex feature to add and, in any case, it's worth a separate ticket (is there one already?). |
By the way by looking at #5641 it seems like this issue only happened with v2-install. What changed? |
Consider this
.cabal
file:I'm choosing to depend on
FPretty
here since it's a package that's known not to build correctly against GHC 8.4 or later. If you try buildingFPretty
in the same directory ascabal-sandbox.cabal
usingnew-build
, then this happens:That's all the output that appears. One might think that this means that
FPretty-1.1
was built successfully, but it turns out that that's not the case at all. In fact, this command actually fails, which is something that you can confirm if you check the exit code:Why, then, does an error message not appear? Quite strange.
This happens with other commands as well, such as
new-repl
:The text was updated successfully, but these errors were encountered: