A manager module for buildsystem "plugins". It deals with the following tasks:
* Handles common command line and environment options. As currently implemented
by the patch they are:
- DH_AUTO_BUILDSYSTEM envvar, -m/--build-system - disables autoguessing of
the build system and allows the user to specify which one to use.
- DH_AUTO_BUILDDIRECTORY envvar, -b/--build-directory - option to enable
building outside source if supported by the buildsystem. User can specify
the build directory name or let it be autogenerated (currently
"obj-`dpkg_architecture('DEB_BUILD_GNU_TYPE')`" as per CDBS convention).
Outside source building has an advantage of avoiding sourcedir pollution
which the clean routine cannot deal with properly (at least common in
cmake or autotools case). The "clean" is simple in such a case - just
rm -rf builddir.
- -l/--list - lists all buildsystems known to Dh_Buildsystems along with
their descriptions.
* Manages buildsystem plugins:
- provides a way to list them and collect information about them.
- provides a way to force loading & use of a specific buildsystem.
- determines which build system is applicable to the source in question using
common API (::is_buildable() method) exposed by each build system plugin.
* @BUILDSYSTEMS variable contains all buildsystems known to the manager in the
order of specialization.
-----------------------------
Contains a few classes which define a common interface for buildsystem plugins
and implements handling of common features (i.e. two types of the build
directory support, see below). Each specific build system plugin is supposed to
inherit from any of these base classes or from another build system plugin.
Currently implemented classes (packages) inside this .pm are:
-- Dh_Buildsystem_Basic --
a basic class describing buildsystem plugin API. It stores build directory
internally (can be retrieved with ::get_builddir() or path constructed using
::get_buildpath() (useful in is_buildable())) but does nothing with it. This
class is intended to be inherited by the build system plugins which do not
support outside-source tree building or there is no way to control this option
(as far as tell, Build.PL is like this). It also describes common buildsystem
plugin API and lays down the basic architecture:
* ::configure/::build/::test/::install/::clean methods - they will be called to
perform a respective action. These are wrapper methods by default and provide
a place to implement common features specific the action itself (like
creating build directory, see Dh_Buildsystem_Chdir::configure()) before
calling real buildsystem specific implementation. Default implementations
call the respective *_impl() method via another invoke_impl() wrapper.
* ::configure_impl/::build_impl/::test_impl/::install_impl/::clean-impl methods
- placeholders for the buildsystem specific implementation of the action (by
overriding the methods as needed). Default implementations do nothing.
* ::invoke_impl($method_name, @args) - a convenient way to hook in the code
which needs to be run before or after respective ::*_impl() of *each* action
(e.g. a simple case like setting envvar, see perl_build.pm). Default
implementation calls $self->$method_name(@args) by default.
So we have such a chain by default (and each can be overriden by any derived
class):
$self->$action() calls:
$self->invoke_impl("${action}_impl", @_) calls:
$self->$action_impl(@_) <- does buildsystem specific stuff here;
-- Dh_Buildsystem_Option --
extends Dh_Buildsystem_Basic and adds support for passing build directory name
via command line option to the build script (specific plugins should override
::get_builddir_option() method). ::invoke_impl() is overriden to pass value of
$self->get_builddir_option() to each ::$action_impl() method (python distutils
use such a way to set "build place", i.e. --build-place=builddir, see
python_distutils.pm).
-- Dh_Buildsystem_Chdir --
extends Dh_Buildsystem_Option. This class implements support for outside source
building when you need to chdir to the building directory before building (like e.g.
makefile.pm and its derivatives: autotools.pm and cmake.pm). All the code in there
deals with chdir'ing/mkdir'ing to the build directory as needed before calling
::$action_impl() and finally going back. This is done by overriding ::invoke_impl()
method.
-----------------------------
-----------------------------
And finally we have build system specific plugins as Debian/Debhelper/Buildsystem/*.pm.
Currently I have implemented 100% functionality of the former dh_auto_* tools
inside these plugins + cmake support in the cmake.pm:
$ ./dh_auto_configure -l
autotools - support for building GNU Autotools based packages.
cmake - support for building CMake based packages (outside-source tree only).
perl_build - support for building Perl Build.PL based packages (in-source only).
perl_makefile - support for building Perl Makefile.PL based packages (in-source only).
python_distutils - support for building Python distutils based packages.
makefile - support for building Makefile based packages (make && make install).
Current plugin inheritance hierarchy is like this:
Buildsystem::perl_build -> Dh_Buildsystem_Basic <- Buildsystem::perl_makefile
^ (maybe it should derive from ::perl_build?)
|
Buildsystem::python_distutils -> Dh_Buildsystem_Option
^
|
Dh_Buildsystem_Chdir
^
|
Buildsystem::makefile
^ ^
/ \
Buildsystem::autotools Buildsystem::cmake
Joey Hess [Tue, 31 Mar 2009 18:09:08 +0000 (14:09 -0400)]
dh_desktop: Avoid using find -execdir as it will fail with certian badly configured PATHs (and is not a benefit in this context anyway). Closes: #521960
Modestas Vainius [Mon, 23 Mar 2009 00:23:17 +0000 (02:23 +0200)]
Add a global --remaining-packages option.
Add a global --remaining-packages option which allows to skip the command on
the packages which it has already been run on (i.e. if the command helper is
already present in the package debhelper log).
Joey Hess [Sat, 21 Mar 2009 01:38:24 +0000 (21:38 -0400)]
Fix calling the same helper for separate packages in the override of dh binary-indep/binary-arch. Closes: #520567
This is based on some work by Modestas Vainius, somewhat simplified
by a trick using excludes.
Note that the error in the case where there are no packages to build was
changed to a warning. That can easily happen now, and doesn't seem
particilarly error-worthy anyway; just exiting w/o doing anything seems
fine in that case.
Joey Hess [Sat, 21 Mar 2009 01:24:30 +0000 (21:24 -0400)]
pass -N into DH_INTERNAL_OPTIONS
I think I didn't do this before because it could result in
parseoptions() erroring because there were no packages to act on.
That is not going to be an error soon though, and it makes sense to
pass in the -N excludes.
Joey Hess [Mon, 9 Mar 2009 20:18:39 +0000 (16:18 -0400)]
Revert "dh_installmenus: Now that a triggers capable menu and dpkg are in stable, menu does not need to be explicitly run in maintainer scripts, except for packages with menu-methods files. (See #473467)"
Joey Hess [Fri, 6 Mar 2009 19:02:15 +0000 (14:02 -0500)]
dh_installmenus: Now that a triggers capable menu and dpkg are in stable, menu does not need to be explicitly run in maintainer scripts, except for packages with menu-methods files. (See #473467)
Joey Hess [Tue, 3 Mar 2009 02:20:29 +0000 (21:20 -0500)]
conffile moving idiocy
* dh_installmodules: Give files in /etc/modprobe.d a .conf
syntax, as required by new module-init-tools.
* dh_installmodules: Add preinst and postinst code to handle
cleanly renaming the modprobe.d files on upgrade.
* Two updates to conffile moving code from wiki:
- Support case where the conffile name is a substring of another
conffile's name.
- Support case where dpkg-query says the file is obsolete.
Joey Hess [Tue, 17 Feb 2009 17:33:57 +0000 (12:33 -0500)]
make dh override_dh_* a no-op
This happens if the override target is completly empty.
Make sees it is, and runs the implicit dh target.
(cherry picked from commit 86fbd6038ee5b7222efa774751fcceedeffedfc2)
Joey Hess [Fri, 27 Feb 2009 20:12:58 +0000 (15:12 -0500)]
dh: Support debian/rules calling make with -B
That is useful to avoid issues with phony implicit rules
(see bug #509756).
Apparently make treats the name of the Makfile as an automaticall
set up target, so this causes it to try to build the Makefile
even though it's up-to-date, and the implicit target
makes it run 'dh debian/rules'.
Joey Hess [Fri, 27 Feb 2009 20:11:25 +0000 (15:11 -0500)]
dh override targets
* dh: debian/rules override targets can change what is run
for a specific debhelper command in a sequence.
* dh: Redid all the examples to use override targets, since these
eliminate all annoying boilerplate and are much easier to understand
than the old method.
* Remove rules.simple example, there's no need to use explcit targets
with dh anymore.
(cherry picked from commit 0f3f59fe6058edfda4010dc88bd3b8aa3ae70a6d)
Joey Hess [Mon, 23 Feb 2009 18:31:11 +0000 (13:31 -0500)]
dh_gencontrol: No longer need to generate the udeb filename when calling dpkg-gencontrol.
* dh_gencontrol: No longer need to generate the udeb filename
when calling dpkg-gencontrol.
* dh_gencontrol: Do not need to tell dpkg-gencontol not to
include the Homepage field in udebs (fixed in dpkg-dev 1.14.17).
Joey Hess [Tue, 17 Feb 2009 17:21:01 +0000 (12:21 -0500)]
dh: Support debian/rules calling make with -B
That is useful to avoid issues with phony implicit rules
(see bug #509756).
Apparently make treats the name of the Makfile as an automaticall
set up target, so this causes it to try to build the Makefile
even though it's up-to-date, and the implicit target
makes it run 'dh debian/rules'.
Joey Hess [Mon, 16 Feb 2009 19:55:55 +0000 (14:55 -0500)]
dh override targets
* dh: debian/rules override targets can change what is run
for a specific debhelper command in a sequence.
* dh: Redid all the examples to use override targets, since these
eliminate all annoying boilerplate and are much easier to understand
than the old method.
* Remove rules.simple example, there's no need to use explcit targets
with dh anymore.
Joey Hess [Mon, 15 Dec 2008 03:13:32 +0000 (22:13 -0500)]
Ignore unknown options in DH_OPTIONS. Debhelper will always ignore such options, even when unknown command-line options are converted back to an error. This allows (ab)using DH_OPTIONS to pass command-specific options. (Note that getopt will warn about such unknown options. Eliminating this warning without reimplementing much of Getopt::Long wasn't practical.)
* If any third-party debhelper commands use any of the above options,
they will be broken, and need to be changed to pass options to init().
* To avoid breaking rules files that pass options to commands that do not
use them, debhelper will now only warn if it encounters an unknown
option. This will be converted back to an error later.
Joey Hess [Tue, 21 Oct 2008 18:00:09 +0000 (14:00 -0400)]
Allow individual debhelper programs to define their own special options by passing a hash to init(), which is later passed on the Getopt::Long. Closes: #370823