gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tom Lord
Subject: Re: [Gnu-arch-users] Re: Online book for usability
Date: Sun, 27 Jun 2004 09:18:04 -0700 (PDT)


    > From: Andrew Suffield <address@hidden>
    >>  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.)

    > This is essentially wrong in general; I don't have any projects where
    > 'inventory' does the same thing as 'make dist'. Nor do I have any
    > projects where 'make distclean' does the same thing as 'inventory -pbj
    > | xargs rm'.

    > The set of files which are stored in the archive, and the set of
    > files which are distributed in tarballs, are similar but
    > distinct.

    > distclean and dist are here because *building a distribution tarball
    > requires building some files to go in it*, not because there might be
    > some unrelated files in the same tree. They're in the GNU conventions
    > because GNU encourages this behaviour, especially for things like
    > bison.

`dist' and `distclean' should be using the same list of files.

Providing that list of files by some independent mechanism, such as
inventory, makes it possible to use generic makefile recipes for those
targets.   The makefile _dependencies_ of `dist' aren't generic, as
you say, but the recipe can be.

I'm not sure why you think `inventory' isn't right for maintaining
that explicit manifest, punning that manifest as the files arch would
archive.   Sure, weirdness can occur if your store built-shipped on a
branch into which people are making merges or are making commits that
change their prereqs without updating them.   There's two reasonable
solutions to that:  (1) don't keep those files on such branches (add them
to release branches);  (2) keep them but learn to manage them
carefully (ala GCC).   If you're shipping them, surely you want them
archived somewhere....


-t





reply via email to

[Prev in Thread] Current Thread [Next in Thread]