Ignore some package trees by default (config file)
bmatsuo opened this issue · comments
I would really like for there to be an optional config file that tells gb to ignore a package subtree. I'll illustrate with an example. A project called go-mypkg with structure
go-mypkg/
|
|- README
|- ignore.gb
`- mypkg/
|
|- workspace.gb
|- mypkg.go
|- ....
|- openglutils/
| |
| `- ...
`- sdlutils/
|
`- ...
The file go-mypkg/ignore.gb could have contents
# Don't install "mypkg/openglutils" or "mypkg/sdlutils" subpackages by default.
mypkg/openglutils
mypkg/sdlutils
If my intentions were not clear from the example. The subpackages "mypkg/openglutils", and "mypkg/sdlutils" are presumably for some kind of easy/assisted integration of "mypkg" with go-opengl and go-sdl. But the programmer of the example doesn't want go-opengl and go-sdl be actual dependencies of "mypkg" because "mypkg" by itself is useful without OpenGL and SDL (the C libs) being installed at all. I hope this makes sense and sounds reasonable. I would really appreciate this feature. (And if it exists, I would like it to be more promenant in the documentation.)
It would be nice to be able to still be able to build these sub-packages by explicitly naming them in the command line. And, if a package being built depends on a package in ignore.gb, the best thing to do would probably be to override ignore.gb and build the package anyway.
Furthermore, it would be nice to be able to place these "ignore.gb" files rooted at any directory in the workspace tree. So, to continue the above example, the go-mypkg/ignore.gb could be moved to go-mypkg/ignore.gb (edit: go-mypkg/mypkg/ignore.gb) and it contents could be altered to
# Don't install "mypkg/openglutils" or "mypkg/sdlutils" subpackages by default.
openglutils
sdlutils
Please consider adding this feature. What go-gb does do is polished and awesome! But I really need a build tool that I can tell to stay out of certain directories.
Feature exists but is not documented - create a file named target.gb with the contents "--" (no quotes), and gb will ignore that directory and any subdirectories. If it is just "-", gb will skip that directory and not its subdirectories.
Treating this issue as a documentation request :)
Also what you suggest is potentially much clearer than a secret code in the target file. I will weigh the costs of clarity vs too-many-damn-file-types and get back to you. Feel free to share your opinion.
Interesting. Thanks a lot for the info, @skelterjohn. That target.gb file will be very helpful for me. Glad to hear it's already implemented =) It would be nice to see in the docs though.
Would it be better to merge target.gb and workspace.gb (and any other configurations) into a single directory-specific config file? It seems like neither workspace.gb or target.gb contain more than a sigle line of text (am I wrong?). So each file's contents could be a single line an appropriately named file config file (something like build.gb or package.gb). Writing a config parser is more work though (or it will introduces a dependency). So do whatever you will with that suggestion. =)
Thanks again for the response.
target.gb seems to work well. So that's awesome! =)
Although, I would like for gb to be able to force a build on targets that are ignored in this way. When I put target.gb in an example cmd's directory and tried to explicitly build it, it get
$ gb examples/tutorial/
gb error: Listed directory "examples/tutorial" doesn't correspond to a known package
$
So, I would need to supply Makefiles for my example cmd's =(
Other than that, as I said, it looks like its all good. Kudos to you at least for thinking of the feature before.
In the meantime, try gb -P (run gb on packages only).
On Tue, Nov 8, 2011 at 10:31 PM, Bryan Matsuo <
reply@reply.github.com>wrote:
target.gb seems to work well. So that's awesome! =)
Although, I would like for gb to be able to force a build on targets that
are ignored in this way. When I put target.gb in an example cmd's
directory and tried to explicitly build it, it get$ gb examples/tutorial/ gb error: Listed directory "examples/tutorial" doesn't correspond to a known package $So, I would need to supply Makefiles for my example cmd's =(
Other than that, as I said, it looks like its all good. Kudos to you at
least for thinking of the feature before.
Reply to this email directly or view it on GitHub:
#24 (comment)
Ahh ok. Should have looked more into that. I still have other reasons for target.gb. But that helps in this case. Thanks a lot!
gb.cfg now has fields ignore and ignoreall, which can be set to true. equivalent to setting target = "-" or "--", respectively.
About the selective compilation thing... I had the same issue with go-gb/example. What I ended up doing was tarballing the directory so gb couldn't find it :)
For distribution, my suggestion is to "gb --makefiles; gb --makefiles pkg1 pkg2 pkg3", so the build script only gets what you want, though everything has a makefile. Then "gb --dist" will make a nice dist directory with everything (including examples+makefiles) and a build script that targets only a portion.
Wow. This all looks great. And it looks like you documented it already too! =)
I was looking at --makefiles earlier today, actually. Haven't tested it. But it seems cool. I'll have to try --dist out as well.
Thanks so much, @skelterjohn.
So... Is gb.cfg only in the weekly branch? I just goinstalled on r60.3 and it's not getting recognized
bryan@magilla$ 8l -V
8l version release.r60.3 9921
bryan@magilla$ goinstall -u -clean go-gb.googlecode.com/hg/gb
bryan@magilla$ cd examples
bryan@magilla$ cat gb.cfg
workspace=..
bryan@magilla$ gb
(in utils) building pkg "utils"
(in mypkg-example) building cmd "mypkg-example"
mypkg-example.go:14: can't find import: examples/utils
Built 1 target
1 broken target
(in mypkg-example) could not build "pkg-example"
bryan@magilla$
If its only in the weekly branch. I wouldn't worry too much about pulling it back. r61 has to come out some time soon... They can't just hold off on stable releases until 2012 with version 1.
Ah, yeah it was only in the weekly.
It's in there, now.
In release now, that is.