Re: Possible framework for `debmake replacement'
On Feb 21, Manoj Srivastava wrote
> >>"Andy" == Andy Mortimer <firstname.lastname@example.org> 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,
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
Everything else, and I emphasize everything, should be done by an
encompassing build utility and controlled by optional configuration
David Engel ODS Networks
email@example.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