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

Re: Possible framework for `debmake replacement'

On Feb 21, Manoj Srivastava wrote
> >>"Andy" == Andy Mortimer <andy.mortimer@poboxes.com> writes:
> Andy> The core of this package would be the helper program(s), which
> Andy> for the sake of this proposal will be a set of programs with the
> Andy> prefix `dmake-'. So for example, dmake-binary would install one
> Andy> or more binaries, according to the current standards (eg,
> Andy> stripped). A possible, probably partial, list of these follows:
> 	I think I'd prefer the helper program to insert commands into
>  the rules file (not necessarily by editing the file in place).
>  Separate programs also make it very hard to see what would happen if
>  I just say ./debian/rules -n binary.

No, no, no!  IMO, this is going in the wrong direction.  We need to
make packages as easy as possible, even trivial, to initially build
and maintain.  This just adds more frame work that a developer has to
initially learn and maintain as policy changes.  My visiion of the
rules file is that it should be strictly limited to the following,
simple targets:

build: Configure and compile the package in place.  A trivial case
would be to run 'configure --prefix=/usr' and then 'make'.

clean: Clean up anything done by the build target.  A trivial case
would be to run 'make distclean'.

install: Install the package (even for multi-binary packages) into a
single "holding directory".  A trivial case would be to run 'make
prefix=debian/tmp install'.

Everything else, and I emphasize everything, should be done by an
encompassing build utility and controlled by optional configuration

David Engel                        ODS Networks
david@sw.ods.com                   1001 E. Arapaho Road
(972) 234-6400                     Richardson, TX  75081

TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com

Reply to: