You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 1, 2023. It is now read-only.
Just wanted to say I already find jd way simpler and more straight-forward than other Go dependency managers. I've just found one teensy weensy little nitpick: build errors don't get pushed back up the stack and aren't shown to the user.
For example, if i build a project that has a build error, I get no error output until I run the build by hand:
ec2-user:code/houston/houston(master✗) jd -v -v
Setting up github.com/tobz/houston
depends on github.com/streadway/amqp at bbc42d384b424cc08732fb935c742fa4fa9e361b
Setting up github.com/streadway/amqp
no dependencies found
Building
running go build
ec2-user:code/houston/houston(master✗) go build -v
github.com/streadway/amqp
github.com/tobz/houston
github.com/tobz/houston/houston
# github.com/tobz/houston/houston
/home/ec2-user/code/go/src/github.com/tobz/houston/houston/main.go:6: imported and not used: "strings"
/home/ec2-user/code/go/src/github.com/tobz/houston/houston/main.go:40: not enough arguments in call to houston.NewConsumer
The text was updated successfully, but these errors were encountered:
I'm glad you're finding it useful @tobz! I had a recurrent problem with GitHub notifications back when you wrote this and I never learnt about this post. Sorry about the delay.
So, you are supposed to get an error output when something fails. The tool works silently unless you specify otherwise, but it should always show compiler errors, no matter the verbosity level. Is there any chance you've wrapped the go binary with some other script, whose error code is not always correct? I suggest you check the exit code from go build. That's how jd detects compiler errors and, when it does, it shows the complete output written by the compiler to either stdout or stderr.
You can try this by using a custom "build" script to fake the compiler. Let's say you write a shell script called build, which is executable and is located at the root of your project. Then jd will run your script for the build phase, instead of calling go build. (This also works with make if you happen to have a Makefile or makefile in that location, which is preferred over the shell script I mentioned before.) Now, jd doesn't care if you're actually compiling your project or not. So, your shell script could simply be:
echo"This failed"exit 1
and, given the non-zero exit code, you should see the message as part of jd's output. Use a zero exit code and the message should stop showing.
I could never see this happening and the code checking the exit code is also quite straightforward. I'm closing this for now. Please reopen if you think we're missing something!
Hey there!
Just wanted to say I already find jd way simpler and more straight-forward than other Go dependency managers. I've just found one teensy weensy little nitpick: build errors don't get pushed back up the stack and aren't shown to the user.
For example, if i build a project that has a build error, I get no error output until I run the build by hand:
The text was updated successfully, but these errors were encountered: