Re: [Pan-users] [OT] Compiling question for KHaley and Heinrich (and everybody)

[Duncan]

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