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

[Tom Lord]

    > From: Juliusz Chroboczek <address@hidden>

    > TL> That particular change to "precious" rather than "unrecognized" was
    > TL> probably a mistake.

    > Could people please explain whence that feeling that building in your
    > working tree is sinful?

That's an over-beers thing.   It's lots of experience and rules of
thumb that converge on that.   A very short clue might be gained by
observing that the GNU Makefile coding conventions call for two
make targets:

        make distclean --- remove all configure and build-products
        make dist -- tar up just the source, nothing else

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.

(At least with `inventory' operations like `make distclean' and `make
dist' become generic: you can implement them just once, trivially, so
that they work for all trees that use `inventory' reasonably.)

But that isn't quite the question here.

The real question is "what should the default for `untagged-source'
be?" 

Some people say that "precious" is a good default because that is one
way to ignore things from in-tree builds.

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.

The safeguard which is `untagged-source unrecognized' _is_ a pain, but
I think it is a pain which is intrinsic in the problems being
addressed.  Among the solutions, in my experience, it is the least
amount of pain.  And if you make the effort to tweak your build
process so that in-tree builds aren't required (which has additional
benefits as well) then you'll feel that minimal pain even less than
minimally:  the feature will only come to your attention when it's
catching a genuine mistake.


    > 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.

Arch isn't the only tool you have issues with without a `make clean'
first unless you also maintain lots of custom tools (like `make
dist').

You can't efficiently copy trees.   You can't tar them up.  You can't
easily grep just the source part of the tree.   You'll run into
problems if you run tags.   Etc.


    > Out of tree builds?  How do you do that in a Makefile with both
    > explicit and implicit rules that is meant to be portable between
    > BSD and SVR4?

Consider relying on GNU Make and read the documentation which tells
you explicitly how to do it.

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.


    > (Extra points if you can tell me how to do something similar in
    > Common Lisp in a manner that is portable between
    > implementations.)

Try comp.lang.lisp

-t