Re: [Gnu-arch-users] Re: Online book for usability

[Jason McCarty]

James Blackwell wrote:
> Tom Lord:
> > With those conventions, GNU admits that once you rely on in-tree
> > builds, you're trees become so hard to manage that familiar tasks
> > which can normally be carried out with generic tools (like tar and
> > find) suddenly require special tools, implemented just for that tree,
> > and constantly maintained along with the tree.
> >
> > I'm saying:  even if you want to get inventory to ignore in-tree
> > build-products, changing `untagged-source' is _not_ the right way to
> > do it.   It's too error prone.   It leads to failing to commit files
> > you add but forget to tag.   It leads to committing files which are
> > build-targets that happen to have source-like names.
> 
> That building-in-trees isn't a flawless practice, that it gets in the
> way of arch, that it raises the possibility of forgetting to add
> something is now present -- _of_course_. 
> 
> But I'm going to play Devil's advocate for a moment. Couldn't it be
> possible that the cure (don't commit when there's untagged source) 
> is more painful to our patients (the users) than the disease (whoops,
> I forgot to add a file?)

Agree, depending on the type of project I'm working on. Sometimes I
prefer to tell arch, "these are the files you need to care about.
Ignore any others."

> >     > In my mind, workdirs are cheap, archives are expensive.  I usually
> >     > have quite a few working directories around, each of which goes the
> >     > way of rm -rf after a few days.  I naturally do my builds in them, and
> >     > it annoys me to no end that I have to make clean before committing.
> >
> 
> Built workdirs are not cheap for moderate to large sized projects. There
> is, after all, a reason that make keeps those object files hanging
> around after the binary has been linked. 

If you're keeping working trees around, is there any reason out-of-tree
build dirs can't be kept around too?

> > If you must rely on your user's native make, consider relying on the
> > auto* tools, although many people use them poorly and don't seem to
> > realize that they support out-of-tree builds.
> 
> The automake utils don't seem to describe out of tree builds. I had to
> ask half a dozen people before I got an answer on how to do it. 
> 
> Even with out of tree builds, autotools builds a lot of "cruft" that I
> don't want to commit. For example, everywhere that I've got a
> Makefile.am, autotools will build a Makefile. 
> 
> Here's the closest that I've gotten to out of tree building: 
> 
> aclocal ; autoheader ; automake -a ; autoconf
> mkdir build ; cd build
> ../configure
> make

I can do a little better than that. I have a ./bootstrap script that
does:

  rm -rf '=build'
  mkdir -p '=build/include' # autoheader doesn't like creating directories
  ln configure.ac '=build/'
  cd '=build'
  autoconf
  autoheader
  ln -sf /usr/share/misc/config.guess /usr/share/misc/config.sub ./
  touch install-sh

You could stick "./configure ; make" in there too, of course. All the
autocruft ends up in =build, and ./configure automatically considers ../
to be the source dir since AC_CONFIG_SRCDIR isn't present in =build. The
trick is to put (or link) configure.ac inside the build directory. I'm
not sure what extra steps are needed for automake though.

> [autocruft]
> 
> And this is supposedly "build-out-of-tree" I don't want all that
> autocruft in my archive! 
> 
> In order to commit, I'm actually performing the following process: 
> 
> Hack, hack hack
> ./BUILD
> debug, debug, debug
> ./UNBUILD
> commit
> 
> (rinse, lather, repeat)

My whole build tree is precious, so no problem.

-- 
Jason McCarty <address@hidden>