problem with gb.cfg, workspace=

[Ian Smith]

Here is the output of gb -s in a directory with many targets:

pkg "mongrel2" (up to date)
pkg "seven5/dsl" (up to date)
pkg "seven5" (up to date)
cmd "tune" in seven5/tune (up to date)
pkg "samples/echo_chat" (up to date)
cmd "webapp_start" in samples/echo_chat/webapp_start (up to date)
pkg "samples/better_chat" (up to date)
cmd "rock_on" in seven5/rock_on (up to date)
cmd "sample2" in mongrel2/sample2 (up to date)
cmd "sample1" in mongrel2/sample1 (up to date)

However if I go into the directory "samples/better_chat" (which is a target above) and run gb -s I get:

Running gb in workspace /Volumes/External/seven5dev
pkg "seven5/dsl" (up to date)  
pkg "samples/better_chat" (up to date)

You can see from the first line that it is picking up my gb.cfg file which has:

workspace = ../..

The workspace feature of the gb.cfg would be absolutely great for my use of gb...

thanks
ian smith

[John Asmuth]

This is the intended behavior. Running gb from directory x/y/z with workspace ../.. is the same as running "gb y/z" from directory x. That is, it will only try to build the things in x/y/z and the stuff it depends on.

Based on the gb -s output, it looks like the only local dep betterchat has is the dsl pkg, and that the dsl pkg has no local deps.

The idea is that you can zoom in to one target's directory, work on its source and then build it correctly without dealing with irrelevant parts on the project.

[Ian Smith]

John:

Thanks for your prompt reply.

The intended behavior would be great unless you are co-developing two
different parts of the same project, as I am. So, I need the "full build"
behavior of the workspace (at ../..) not the, admitedly very clever, "zoom
in" build behavior.

Perhaps there's a flag on gb.cfg that could say, "build anything that has
changed" ??

If you are wondering, I'm working on http://seven5.github.com/seven5 ...
which actually has a tool that monitors a user-level project to see if any
go files have changed. If it detects something has changed, it naturally
invokes gb to rebuild it! However, because I'm working on the "monitoring
part" with a "sample" project, I need everything to build...

gb rocks!

ian

On Fri, Dec 2, 2011 at 3:03 PM, John Asmuth <
[e-mail]

wrote:

This is the intended behavior. Running gb from directory x/y/z with
workspace ../.. is the same as running "gb y/z" from directory x. That is,
it will only try to build the things in x/y/z and the stuff it depends on.

Based on the gb -s output, it looks like the only local dep betterchat has
is the dsl pkg, and that the dsl pkg has no local deps.

The idea is that you can zoom in to one target's directory, work on its
source and then build it correctly without dealing with irrelevant parts on
the project.

---

Reply to this email directly or view it on GitHub:
#28 (comment)