Re: DebCamp work for pkg-perl?
Hi,
On Jan 7, 2008 9:31 AM, Damyan Ivanov <dmn@debian.org> wrote:
> The current approach tries to be all-in-one, which may be a bit
> overreaching. Perhaps we can provide two files for arch-indep and
> arch-dep modules, and one common that is included from both.
I started that way, but then I discovered that they differ very little
(4 lines or so). And in this way, it somewhat supports multi-binary
packages (even mixing arch-indep/dep packages), for very simple cases,
of course.
> I am also a bit worried that some properties of the makefile are
> controlled by the presence of some files/dirs. I'd make it
> varriable-driven. I mean - patch system used, build method (MakeMaker
> vs. Module::Build). Imagine a dpatch named "series" or a quilt patch
> named "00list" -- confusing for everyone. It is also common for
I don't understand that.. Maybe you have misread the code. The thing
triggered by the debian/patches directory is only the usage of a patch
system. The patch system used is always determined by the value of
PATCH_SYS variable (which defaults to quilt, but the default could be
removed).
> Module::Build-using modules to also provide Makefile.PL for backwards
> compatibility.
Yes, that's why I check for Module-Build first. But it could be
modified so the automatic detection is overriden.
> I also dislike that dh_install* calls are driven by the presence of
> debian/$pkg.* files. I just prefer to review one file (debian/rules)
> instead of many. This can be avoided at the cost of some uglification by
> using variables. For example
Remember that dh_install* will look at those files even if you specify
filenames on the command line. And yes, you could add variables like
you say below, I'd just use DEB_INSTALL_DOCS = blah and then call
dh_install $(DEB_INSTALL_DOCS). Remembering that if you have a
multibinary, those docs gets installed in all packages.
> SUPMBS_DOCS := auto # default, let dh_installdocs look for debian/docs
> := README # generates "dh_installdocs README"
> SUPMBS_LINKS := <empty> # default; omit the call to dh_link
>
> I also understand that this approach currently supports extension via
> the makefile target:: syntax, which means adding to the targets, i.e.
> clean::
> rm some/forgotten/file
No exactly. To be able to do that, every target must be made
double-colon-type, it can be done.
Also, you could extend it by adding prerequisites to single-colon-type
targets, and then in those prerequisites add your stuff.
> I am not sure how to improve this (and if it is worth it):
>
> pre-clean: # empty by default
> clean: pre-clean
> # simplified. Build.PL...
> [ ! -e Makefile ] || $(MAKE) distclean
>
> With this, one could extend pre-clean:: to put something before the
> "standard" clean
Behold, as that path leads to madness! :)
I started thinking along these lines, and ended re-implementing cdbs :)
> Too bad that makefiles don't have user-defined functions :(
>
> Finally, I am not sure how will this work for more complicated,
> multi-binary packages. Even if it doesn't, simplifying mass-changes to
> the majort part of our packages would be a huge benefit.
What I don't like is that it is quite complicated to extend or
generalize more this script. That's why I'm not very happy with it,
but it could be used after some polishing for the majority of our
packages, they are really simple.
BUT, if we want something more flexible/generic, I think that we'd use
better our effort if we wrote and correctly documented a plugin for
cdbs (the current perl plugin is too simple), or take cdbs, strip out
all the stupid stuff (like the capability to rewrite debian/control)
and then use that.
What do you think?
--
Martín Ferrari
Reply to: