Comments (7)
@fatih I agree and I'll do this. At the moment the error message are without a path because the build is compiled with the working directory set to the src directory of the package.
As a simplistic fix, always executing the build from a single location will give more inspectable error message.
I'd like to avoid making the paths absolute initially, I'd rather everything was relative to $PROJECT
or $PROJECT/src/
. @fatih, do you have any preferences ?
from gb.
I feel that file paths in messages should be relative to $PROJECT
.
gb
is all about thinking in terms of projects. This should be reflected in how it communicates with users.
from gb.
There is a small inconsistency that you ask for a package to be built by
its import path, but the error message will have src/ stuck on the front. I
think this I'd manageable, and preferable to making the paths relative to
$PROJECT/src/ as it makes it more complicated if the error is in a vendored
package.
On Sat, 9 May 2015 13:02 Ukiah Supermighty Smith [email protected]
wrote:
I feel that file paths in messages should be relative to $PROJECT.
gb is all about thinking in terms of projects. This should be reflected
in how it communicates with users.—
Reply to this email directly or view it on GitHub
#57 (comment).
from gb.
What are other things that would be affected by this decision? Tooling? Copy/Paste from terminal? How does the choice of path make life easier or harder to be a drop-in replacement for the go tool?
from gb.
If it makes it easier for @fatih to integrate gb I to go-vim, I can only
see this as a positive for other tools that want to integrate.
On Sat, 9 May 2015 13:13 Ukiah Supermighty Smith [email protected]
wrote:
What are other things that would be affected by this decision? Tooling?
Copy/Paste from terminal? How does the choice of path make life easier or
harder to be a drop-in replacement for the go tool?—
Reply to this email directly or view it on GitHub
#57 (comment).
from gb.
@fatih I agree and I'll do this. At the moment the error message are without a path because the build is compiled with the working directory set to the src directory of the package.
Thanks a lot @davecheney, this will make it easier to integrate gb
with editors.
As a simplistic fix, always executing the build from a single location will give more inspectable error message.
Right. I was executing gb build
in the root folder. To test how the path is printed I've introduced an error in a new subfolder: github.com/fatih/color/subcolor
. The error was in the form:
subcolor.go:5: non-declaration statement outside function body
However there is no context here, does the file belong to github.com/fatih/color
or github.com/fatih/color/subcolor
? (Correct answer is the latter one). So here gb build
evaluated in the root folder. But of course in the editor, the build will be always from within the source code's location (github.com/fatih/color
)
I'd like to avoid making the paths absolute initially, I'd rather everything was relative to $PROJECT or $PROJECT/src/. @fatih, do you have any preferences ?
Relative is imho a good choice to go (because it's the same with the go tools). Because it's relative, it doesn't matter exactly from where it's called right? For example this is how go build
is acting:
fatih git:master ❯ pwd
/Users/fatih/Code/koding/go/src/github.com/fatih
fatih git:master ❯ go build ./color
# github.com/fatih/color
color/color.go:79: undefined: a
fatih git:master ❯ cd color
color git:master ❯ go build
# github.com/fatih/color
./color.go:79: undefined: a
color git:master ❯ cd foo/bar
bar git:master ❯ pwd
/Users/fatih/Code/koding/go/src/github.com/fatih/color/foo/bar
bar git:master ❯ go build ../../.
# github.com/fatih/color
../../color.go:79: undefined: a
For example some users have a autocmd in their vimrc, which is automatically joining the directory of the current buffer's location. However some are in a completely different location but are working on the same buffer. In vim-go
, what I do is, regardless of the user's directory, I enter into the current buffer's directory and execute go build
. This makes things very easy for me, because as seen above I'll get always the correct path.
Now for gb
, I can do the same but as reported in my first reply, it's printing differently. Here is an example:
The error is in the github.com/fatih/color/subcolor
package obviously, but I don't have any context to the file name.
from gb.
Got it, fix coming soon.
On 10 May 2015, at 06:11, Fatih Arslan [email protected] wrote:
@fatih I agree and I'll do this. At the moment the error message are without a path because the build is compiled with the working directory set to the src directory of the package.
Thanks a lot @davecheney, this will make it easier to integrate gb with editors.
As a simplistic fix, always executing the build from a single location will give more inspectable error message.
Right. I was executing gb build in the root folder. To test how the path is printed I've introduced an error in a new subfolder: github.com/fatih/color/subcolor. The error was in the form:
subcolor.go:78: c evaluated but not used
However there is no context here, does the file belong to github.com/fatih/color or github.com/fatih/color/subcolor? (Correct answer is the latter one). So here gb build evaluated in the root folder. But of course in the editor, the build will be always from within the source code's location (github.com/fatih/color)
I'd like to avoid making the paths absolute initially, I'd rather everything was relative to $PROJECT or $PROJECT/src/. @fatih, do you have any preferences ?
Relative is imho a good choice to go (because it's the same with the go tools). Because it's relative, it doesn't matter exactly from where it's called right? For example this is how go build is acting:
fatih git:master ❯ pwd
/Users/fatih/Code/koding/go/src/github.com/fatih
fatih git:master ❯ go build ./colorgithub.com/fatih/color
color/color.go:79: undefined: a
fatih git:master ❯ cd color
color git:master ❯ go buildgithub.com/fatih/color
./color.go:79: undefined: a
color git:master ❯ cd foo/bar
bar git:master ❯ pwd
/Users/fatih/Code/koding/go/src/github.com/fatih/color/foo/bar
bar git:master ❯ go build ../../.github.com/fatih/color
../../color.go:79: undefined: a
For example some users have a autocmd in their vimrc, which is automatically joining the directory of the current buffer's location. However some are in a completely different location but are working on the same buffer. In vim-go, what I do is, regardless of the user's directory, I enter into the current buffer's directory and execute go build. This makes things very easy for me, because as seen above I'll get always the correct path.
Now for gb, I can do the same but as reported in my first reply, it's printing differently. Here is an example:
The error is in the github.com/fatih/color/subcolor package obviously, but I don't have any context to the file name.
—
Reply to this email directly or view it on GitHub.
from gb.
Related Issues (20)
- gb should fail early with unknown/unsupported GOOS or GOARCH value
- Error vendoring gb with gb-vendor HOT 2
- gb build does not create bin folder and binary in bin folder HOT 24
- Website needs list of projects using GB
- Gogland (perhaps also others) configuration example HOT 1
- why vendor/src? HOT 1
- gb build fails on centos7 with linking error HOT 6
- have any command copy a package from $GOPATH
- Can't build project in Docker HOT 2
- gb build do not work correctly on windows (can work correctly on linux)
- Build of Go's runtime package fails when cross-compiling with go1.9.4 HOT 6
- horizon HOT 4
- using gb to make a library HOT 2
- Is the gb project dead? HOT 15
- / HOT 1
- gb vendor doesn't work with fish shell HOT 1
- [SOLVED] How to migrate to go modules? HOT 6
- gb + IDE ? HOT 1
- Cross build not working on OSX: cgo_export_static main only allowed in cgo-generated code
- module github.com/constabulary/gb@latest found (v0.4.4), but does not contain package github.com/constabulary/gb/internal/vendor HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gb.