Re: debstd-like tool for those who don't want to use debmake
On Mon, 22 Sep 1997, Christian Schwarz wrote:
> I must admit I don't know any details about automake so please correct me
> if I'm totally wrong. It looks like automake is like imake but much more
> flexible.
I'm not an automake or autoconf expert, but I think it's something as a
macro expander with a big set of macros predefined.
> Joey's idea (at least what I think is his idea, based on the discussion on
> debian-policy) was to build a replacement for debstd since debstd is
> already "doing to much" which makes it unusable for larger/more
> complicated packages.
>
> His approach looks perfect since it actually splits up the functionality
> of debstd into smaller pieces which makes it much more transparent. And if
> one still does not know what's going on, one can use his commands to
> create the actually commands to be pasted into debian/rules.
>
> I think if we'd use automake (or a similar tool) the effect would be the
> opposite.
How would it be? As you said, the main benefits of splitting debstd are:
- modularity: you won't have a big tool that does everything, so you can
easily add or remove one step.
- transparency: the little scripts are easier to read than the big one,
and one can even use the actual commands, instead of the script,
building an independent debian/rules
With an autorules approach, the mantainer writes the debian/rules.ar file,
using macro names instead of calling the little scripts (same modularity).
Then, he does "autorules debian/rules.ar" and that command expand the
macros to build the final debian/rules The final debian/rules contains the
actual commands, so there's no little script needed to build the package,
and you don't have to inspect other files to see what will be done when
you execute "debian/rules binary". (total transparency) :-)
If sometime policy is changed (say we decide to change the upstream
changlog file name), just ship an updated autorules (perhaps even in
dpkg-dev), and all the maintainer will have to do is reexecute "autorules
debian/rules.ar" to update his rules file to the latest policy.
As an example, fragments of the relevant files shipped with each source
package, using proposed methods, may look like:
* using Joey's idea:
(debian/rules)
binary-arch: (checkroot)
...
joey-install-binaries
joey-install-docs README doc.ps blah.html
...
* with autorules:
(debian/rules.ar)
binary-arch:
...
AR_INSTALL_BIN
AR_INSTALL_DOCS (README, doc.ps, blah.html)
...
(debian/rules generated by the maintainer with "autorules debian/rules.ar")
binary-arch:
...
make install PREFIX=`pwd`/debian/tmp
install -m 644 -o root -g root README doc.ps blah.html \
`pwd`/debian/tmp/usr/doc/$(package)/
gzip `pwd`/debian/tmp/usr/doc/$(package)/{README,doc.ps,blah.html}
...
See, the rules.ar doesn't look more obscure than the debian/rules with Joey's
idea, but the rules file is now generated automatically using autorules,
instead of manually editing, and you can see the commands there. Also, you
won't need autorules to rebuild the binary packages, as you will have the
complete rules file in the source package.
And if someone wants to know what each macro used in the rules.ar
file does, they can read the autorules docs or sources, just
as they would do with the tiny scripts, or just try and check the results
in their generated debian/rules.
> (If you think I missed automake purposes totally--which is likely to be
> the case--please show me how a new debian/rules file would look like.)
That's the beauty of the autorules idea. :-) The final debian/rules would
look like a usual one without debstd, but you won't have to write that file
if you don't need to, just generate the smaller and cleaner rules.ar,
and let the autorules macro expander do the dirty job. :-)
You can even add some fragments of a rules file in rules.ar, and
the macro expander will copy them to the generated debian/rules without
modification, so no functionality is lost.
Thanks,
--
Enrique Zanardi ezanardi@ull.es
Dpto. Fisica Fundamental y Experimental Univ. de La Laguna
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: