walt posted on Fri, 01 Jul 2011 15:37:07 -0700 as excerpted: > I just pulled from both git repositories and compiled as usual in each > repository. My build completed in KHaley's repo but stopped prematurely > in Heinrich's repo. > > Let me explain: > > Maybe I'm a bit different from most (just ask my wife) but I *hate* > compiling sources in the source directory itself, i.e. compiling > "in-tree". > > Instead, I always mkdir obj; cd obj; ../configure --prefix=$HOME so I > install in my home directory and I don't leave compiler droppings on the > clean white carpet ;)
> So, my question is how to make sure that a project will compile > "out-of-tree" (in an obj or build directory)? Since we're talking about git, here, there's actually (at least) two ways to handle this. 1) Make your remote repo clone "--bare" or "--mirror" (see the git-clone manpage for the difference, mirror's good if you don't intend to do any modifications of your own), that is, clone the administrative files only, without creating a working directory and doing a checkout. That will save you the room taken by the working dir checkout when you're not using it (instead of putting the admin files in <dir>/.git, they go in <dir> itself, so there's no place to put the checkout, you just have all the information about the repo that's normally found in .git). You can't / get/ cleaner than not having a working directory at all! =:^) To get a working dir, then, you use git clone again, but this time against the bare repo on the local machine, using the --local and --shared options and without --bare. This effectively creates your working dir, with the objects in its .git hard-linked (if possible, keep it on the same partition, as it would naturally be if you had used the non-bare clone it's replacing, and it should be possible) to the original bare clone, thus saving space (and making the clone faster since it's not copying all that data, only hardlinking it) over a regular clone. You can then blow away the --shared working copy any time you want (creating a new one each time you build, for instance), without affecting the original bare/mirror clone. Do note, however, the warnings under the --shared option -- if you delete branches, etc, in a --shared clone, it CAN affect the original clone (if the branch is in the original, if you just created it in the shared, it won't be), altho if your intent is simply to follow the upstream repo, not do development of your own, no big deal since the next pull will straighten things out again (and you'd be unlikely to be doing stuff like deleting branches found in the original clone in that case anyway, since that's the sort of actions devs would do, not users simply following the upstream repo). A good read of the git-clone manpage, or git help clone (the result is the same), should clear up most questions about the git clone options and their effects, exact command syntax to use, etc. (FWIW, while I'm gradually getting more comfortable with git, since I'm on Gentoo I was able to "cheat" on this, by looking at what the gentoo git-2.eclass ebuild helper library did. It uses this approach to bare- clone a repo into the package sources area, then shared-clone the bare- clone into the temporary build area used to build packages. The shared- clone is thus single-use, then blown away along with the whole temporary package build when it's done. As I have my temporary build area as a tmpfs mount, the whole shared clone and build is effectively done in memory, meaning it really *IS* as temporary as anything in memory is. But the package sources area bare-clone remains and is auto-pull-updated the next time the git-repo-sourced package is built.) 2) Using a normal non-bare clone, you can do a simple rm * (not .*, so it doesn't remove the .git subdir) and blow away the whole checkout, including all the "compiler droppings" (nice metaphor, BTW), then simply do a new checkout --force to build a new clean working tree. Of course, those options are provided by git, over and above anything provided by the build system (like the Linux kernel's make clean and make mrproper, and the KBUILD_OUTPUT variable it honors -- I use the latter here to build in a subdir, while using .git/info/exclude to exclude that subdir in my local kernel git tree). Assuming a traditional autotools based build, ./configure (or in your case ../configure) --help gives its options. --srcdir=DIR looks interesting, here. It also looks like copying/linking the configure into your working subdir might work, as it checks its parent dir automatically. However, I've not actually tried either one with pan to see if it actually works. You can also play various games with links. If you create a dir and then either hard- or sym-link the sources tree into it (being sure to create actual subdirs and link only files, not dirs), again, you effectively create a working dir which you can blow away without blowing away the original sources dir and its contents, but where any "droppings" will remain in the working copy. Obviously you'd create a script to do this for you, then simply run it when you want to build something, then blow away the resulting working dir, afterward. I believe this actually used to be very common, when people built from tarballs much more frequently than they do in this age of binary packages, and SCMs that make checking out clean versions from their live trees a routine thing. As such, there's probably pre-built scripts around for it, but I'm not sure what they'd be called or how one would go about finding them. But building your own shouldn't be /too/ difficult, if you're at all handy with shell scripting. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/pan-users
