Re: autotools not suited to proprietary development?

[Russ Allbery]

Tim Van Holder <address@hidden> writes:

> They do the equivalent of

>   <extract tarball>
>   <apply distro patches>
>   ./configure --prefix=/usr <other switches as needed>
>   make (possibly "make check" instead)
>   make install DESTDIR=<distro package staging area>
>   cd <distro package staging area>
>   <build package using current dir as root dir>

The cd isn't really necessary (Debian packages as a rule don't cd, but
instead use debian/tmp or debian/<package> inside the unpacked source
package as the staging area), but essentially yes.

> I think they tend to use chroot for "make install" so non-automake trees
> work as required (as do automake-based trees with non-DESTDIR-handling
> custom rules), but that's basically all there is to it.

chroot turns out not to be necessary, plus would make it impossible to
build packages as normal users, something that one wants to do whenever
possible.  (Debian uses a supporting program called fakeroot that takes
care of tracking chowns and chmods and ensuring they're captured properly
in the resulting package without having to manifest them in the file
system.)  DESTDIR or changing prefix at install time works with most
things, and when it doesn't work, one usually resorts to reimplementing
the installation rules oneself by just copying things around or using
whatever broken install mechanism is supported and then fixing things up
afterwards.

Now, it *is* common for Debian packages to do the entire package build
operation inside a chroot, but that's more to ensure that the build
environment is consistent with the target Debian platform (which may not
be the same platform the developer's system runs) and to ensure there are
no forgotten build dependencies.

-- 
Russ Allbery (address@hidden)             <http://www.eyrie.org/~eagle/>