Exclude sub-dir
cdunn2001 opened this issue · comments
Many packages include a sub-dir of examples. Those should be built only from within that sub-dir. Would it make sense to create a file which tells gb, "Do not descend into this sub-dir"? Or maybe a positive file which lists the sub-dirs which should be searched. Or do you think it's better just to let the examples be built by default, as long as they are not installed?
Why does gb skip src directories?
148 if subdir != "src" { 149 ScanDirectory(path.Join(base, subdir), path.Join(dir, subdir))
I'm trying to set up a package in the standard way for goinstall, but I'd like it to work with gb as well. What do you recommend?
Regarding not descending into subdirs... there is a way. target.gb with contents "--". If it's just "-", this one directory is ignored but those below are still scanned. I don't believe this was documented. It is, now.
Regarding not descending into "src"... this is a bug! It's left-over from before when if your target's directory had a source directory in it, all source files contained within went to this target (rather than becoming their own targets). I've fixed this in the latest commit. Thanks!
From golang forum:
If gb doesn't work somewhere when goinstall does, let me know (it's a bug).
Well, ok. It seemed to have a problem when run somewhere underneath a GOPATH directory. Maybe I can try again and send you a link. We are trying to use gb on the generated code, but goinstall on the generating code, since the generated code does not need installation and would require tons of makefiles. Make sense?
Thanks.
When I run gb from within a $GOPATH dir, it works as I expect. Can you give me an example directory structure, the command you run (and the working directory), what happens and what you expect to happen?
mkdir foo/src export GOPATH=foo/src goinstall github.com/bketelsen/skynet/skylib goinstall github.com/bketelsen/skynet/skygen cd foo/src/github.com/bketelsen/skynet/skygen gb -v -i
What happens for you? I've tried adding a 'target' comment, but it's not helping.
$ gb skygen Running gb in GOPATH /Users/cdunn2001/dev/gh/GOPATH/src gb error: Listed directory "github.com/bketelsen/skynet/skygen/skygen" doesn't correspond to a known package
gb works, but "gb skygen" does not. That's the problem....
I guess I have to run from the proper directory, or create a workspace.gb file?
I had thought this is all too painful, until I learned how broken goinstall is. At least gb is configurable.
skynet/skygen/workspace.gb:
..
That should work, no? How do I compile skygen from inside the skygen directory? Or from above the skynet directory?
Ok. Couple things here.
The command lines you give to gb are never the target names - they are always the directories containing source. When you try to run "gb skygen" from "foo/src/github.com/bketelsen/skynet/skygen", it looks for code in "foo/src/github.com/bketelsen/skynet/skygen/skygen". There is none - but there is code in the current directory. That is why "gb" by itself works - listing no directories is equivalent to listing ".". So, the target whose source is in the current directory or any of its sub directories.
workspace.gb files have no meaning from within a GOPATH directory or inside GOROOT.
GOPATH, like workspace.gb, is an attempt to allow compilation of source in one directory as though it were in another directory (so you can get the relative paths correct and know about all the other packages).
It doesn't make sense to use them at the same time. workspace.gb predates the existence GOPATH, or I probably wouldn't have introduced it, though I in general hate configuration-by-env-var and think that workspace.gb is a nicer way to do local projects. Putting things in a GOPATH directory makes sense for global reasons - making that stuff available to everybody. workspace.gb makes sense for self-contained projects.
It occurs to me (looking at the output of "gb -s") that it might be nice to list the directory of cmd targets. I took that away because in my infinite testing, I only tested package listings in $GOPATH directories, and their target names are their directories (and it was redundant and irritating to see it twice for every package).
[targets are] always the directories containing source
gb . works! Perfect. Now I'm catching on.
workspace.gb files have no meaning from within a GOPATH directory or inside GOROOT.
Aha! Thanks.
[I]t might be nice to list the directory of cmd targets.
Well, I'd probably bug you less. :-)
I added some stuff to list the directory for gopath cmds, etc.
I also fixed the tag/branch issue - now there are tags for previous go releases, and the current one is in the release branch. the master branch is for weekly. Much easier to handle, now.
Thanks. You have a clever way to distinguish weekly from release: different VCS and hosts. Haha!
Question: Is master in sync with your googlecode version?
I guess you also should include some sort of note about the old release tag. Anybody with a current check-out needs to delete their local release tag.
git tag -d release
Maybe put that in the README.md?
Note that goinstall -v -u github.com/skelterjohn/go-gb/go does not actually update with the latest changes, at the moment.
Things were no better with the permanent release tag, of course.
By the way, I thought that your release tags were not a bad idea, e.g. gb-release.r58. They're not necessary, but they do show at which points the code was considered "stable".
Another thing: Most people are doing it wrong. You should develop against the golang release. To maintain a branch for the golang weekly, you should create a temp branch from your dev branch, run gofix, and merge the result to your weekly branch. The reason is that you cannot gofix in the reverse direction. Just my opinion, fwiw.
Anyway, everything is perfect from my point of view. Thanks again.
Yes, master is in sync with the googlecode project. In fact I have a set of scripts that commits and pushes to both at the same time, with the same message.
Interesting catch w/ goinstall -u. Not my jurisdiction, however. (I saw your golang-nuts post about it, too)
gofix isn't sufficient for all release->weekly changes... the strings.Split() and sort.StringSlice/StringArray issue, sure, but I also switch to the much more flexible and sensible exp/template for makefile and testmain.go generation. exp/template is only available in weekly, at the moment. It would be an impressive gofix plugin that would automate this!
To backtrack to release, I keep the old stuff in comments, in situ :)
Good info. Thanks. EOF