Symlink to a main package folder

[fzerorubigd]

Inside the src, I have a symlink (ln -s some/path/project project) i can build this with gb build folder but gb build ignore it.

I don't know if this is a bug or not, but I since it's already done (with direct call gb build folder) so it must work in gb build too.

[davecheney]

As we're reusing the logic from go/build, gb ignores symlinks.

Can you include the output of gb build -v folder and gb build -v

[fzerorubigd]

Sorry for delay :)

gb build -v

DEBUG project root "/home/f0rud/funspace/gb-test"
DEBUG matchPackages: [/home/f0rud/funspace/gb-test/src] ...
DEBUG args: []
DEBUG removing work directory: /tmp/gb046930838
DEBUG build duration: 14.913µs map[]

gb build -v example

DEBUG args: [example]
DEBUG loadPackage: example true (/home/f0rud/funspace/gb-test/src/example)
DEBUG buildPackage: example
DEBUG {main example /home/f0rud/funspace/gb-test/src/example} is a main package, not installing
INFO example
DEBUG gc:gc example /home/f0rud/funspace/gb-test /tmp/gb082253620/example/main.a [src/example/main.go]
DEBUG cd /home/f0rud/funspace/gb-test; [/usr/lib/go/pkg/tool/linux_amd64/6g -p example -pack -o /tmp/gb082253620/example/main.a -I /tmp/gb082253620 -I /home/f0rud/funspace/gb-test/pkg/linux/amd64 -complete src/example/main.go]
DEBUG cd .; [/usr/lib/go/pkg/tool/linux_amd64/6l -o /home/f0rud/funspace/gb-test/bin/example -L /tmp/gb082253620 -L /home/f0rud/funspace/gb-test/pkg/linux/amd64 /tmp/gb082253620/example/main.a]
DEBUG removing work directory: /tmp/gb082253620
DEBUG build duration: 258.771146ms map[link:224.896097ms compile:33.323909ms]

[fzerorubigd]

And the tree :

.
├── bin
│   └── example
├── example
│   └── main.go
└── src
    └── example -> ../example/

4 directories, 2 files

The main.go is the minimum go main file.

[davecheney]

Thanks for the reproduction. There are two parts to the answer.

The first part is because gb reuses the package discovery code from go/build it follows the Go authors decision that symlinks are not followed.

The second part is I agree with the Go authors, symlinks inside a project structure means that one piece of code has more than one name, one import path, and can appear more than once in the final binary.

Sorry, I'm not going to add support to gb to handle symlinks inside $PROJECT/src

[fzerorubigd]

@davecheney fair point, as long as the gb build folder can build the symlink, every thing is fine.

But this raise a question for me, if I want to vendor a library with a command, for example go-bindata (https://github.com/jteeuwen/go-bindata), what is the best way in gb?
The problem is, my app need the code as library, and I need exact same version (for compatibility) of that binary (in this case go-bindata). I can not use any version of go-bindata in my machine, just the binary of the code that is inside my vendor folder. (go-bindata is just an example, may be this one is fully backward compatible, but my problem is still there)
How I can force gb to build that in my bin folder (or in vendor/bin )?

ps - currently I use a symlink for that

[davecheney]

This issue is closed, could I ask you to raise a new issue for this new
question so I don't forget it.

On Sat, 16 May 2015 23:53 fzerorubigd notifications@github.com wrote:

@davecheney https://github.com/davecheney fair point, as long as the gb
build folder can build the symlink, every thing is fine.

But this raise a question for me, if I want to vendor a library with a
command, for example go-bindata (https://github.com/jteeuwen/go-bindata),
what is the best way in gb?
The problem is, my app need the code as library, and I need exact same
version (for compatibility) of that binary (in this case go-bindata). I can
not use any version of go-bindata in my machine, just the binary of the
code that is inside my vendor folder. (go-bindata is just an example, may
be this one is fully backward compatible, but my problem is still there)
How I can force gb to build that in my bin folder (or in vendor/bin )?

ps - currently I use a symlink for that

—
Reply to this email directly or view it on GitHub
#91 (comment).