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

[James Blackwell]

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?)

Is building-in-tree even really an issue? Couldn't we really just avoid
95% of the argument if we moved the default for object files, and ectetra
into precious? 

What if we added a commented out line that says "If this project builds
in tree, then we recommend these regexes instead" ? 


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

I respect that your opinion that forgetting to add files is more painful
than cleaning a tree out.

My opinion is the opposite. commits are much more frequent than adding
new files (to be potentially be forgotten) and thus are more painful.

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

When we push "build out of tree or clean your tree before you commit",
we're unintentionally pushing users towards either wiping out precious
object files or delaying commit.

But, and this is a big but, users can *change* the defaults. There is
something else going on here, that users aren't just changing the
defaults, and being done with it. Do users not realize that the defaults
can be changed? Are the regexes scaring them? Do they worry that if they
make a mistake in the regexes they can't fix them? Maybe the regexes are
in the wrong place in the tutorial, and people are skipping that
section? 

*Something* is going on here.

Perhaps the solution is something as simple as giving clear examples on
the list of how to change the defaults to the most recent complainer every
couple months



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

Turns this: 

AUTHORS  CROSS      Makefile.am  README  ToDo     configure.ac  src
BUILD    ChangeLog  NEWS         THANKS  UNBUILD  images        {arch}

into this:

AUTHORS    Makefile.am  UNBUILD         config.sub    mkinstalldirs
BUILD      Makefile.in  aclocal.m4      configure     src
COPYING    NEWS         autom4te.cache  configure.ac  stamp-h.in
CROSS      README       build           images        {arch}
ChangeLog  THANKS       config.guess    install-sh
INSTALL    ToDo         config.h.in     missing


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)


And building out of tree is a pain in the but! Every time I want to
make, I have keep an extra tty going just so that it can sit in the
build dir for me to type "make" in!


>     > (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
>
>
>
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnu-arch-users
>
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/
>


-- 
James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400