summaryrefslogtreecommitdiff
path: root/Debian
Commit message (Collapse)AuthorAge
...
* | remove verbose_print of buildsystem selection detailsJoey Hess2009-04-20
| | | | | | | | | | | | | | | | | | This would be the only place in debhelper where -v enables debugging info that is not just shell commands being run. Since --list can be used to see details of build system selection, and since it will probably be obvious which one is selected in -v mode due to the commands run, I think this oddity is unnecessary.
* | reformat listJoey Hess2009-04-20
| | | | | | | | | | I think this is a bit easier to understand; I was never a fan of complex and hard to read column headers in console output (ie, dpkg -l).
* | reword descriptionsJoey Hess2009-04-20
| | | | | | | | | | Shorten, remove duplicate verbiage, and list the characteristic file of the build system.
* | factor out a buildsystems_listJoey Hess2009-04-20
| |
* | rename Dh_Buildsystem to BuildsystemJoey Hess2009-04-20
| | | | | | | | | | This way the root of the class hierarchy has the same name as the directory holding the classes.
* | use $this rather than $selfJoey Hess2009-04-20
| |
* | let's write class, not clsJoey Hess2009-04-20
| |
* | remove _mkdir, use mkdir -pJoey Hess2009-04-20
| | | | | | | | | | | | | | | | | | | | | | | | | | _mkdir is not necessary, because mkdir's error messages are good enough if a file by the name of the directory exists ("cannot create directory: File exists"), or if a file is where the parent directory should be ("cannot create directory: Not a directory") Using mkdir -p seems useful, in case someone wants a deeply nested builddir. This also changes the return value of mkdir_builddir, but nothing currently tests it.
* | remove discussionJoey Hess2009-04-20
| |
* | removal of comments I'm satisfied withJoey Hess2009-04-15
| |
* | debhelper modular buildsystems (try 3).Modestas Vainius2009-04-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * New feature - when listing buildsystems, list their status too (auto/specified). * Dh_Buildsystem_Basic.pm renamed to Dh_Buildsystem.pm * Addressed a few issues expressed in the comments, answered a few comments. * Cache DEB_BUILD_GNU_TYPE value. Performance hit is noticable when listing build systems. * is_auto_buildable() renamed to check_auto_buildable() (again). Since there is is_buildable() now, I didn't want to use is_ for that method. Signed-off-by: Modestas Vainius <modestas@vainius.eu>
* | more commentsJoey Hess2009-04-14
| |
* | more commentsJoey Hess2009-04-14
| |
* | more commentsJoey Hess2009-04-14
| |
* | update and remove XXX commentsJoey Hess2009-04-14
| |
* | Modular object-orientied buildsystem implementation (try 2).Modestas Vainius2009-04-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Major changess: * Dh_Buildsystem_Option dropped and Dh_Buildsystem_Chdir functionality partitially merged into Dh_Buildsystem_Basic. Dh_Buildsystem_Bases.pm renamed to Dh_Buildsystem_Basic.pm to match classname. * *_impl() ditched completely. Previous {configure,build,test,install,clean}_impl() renamed to just configure(), build(), test(), install(), clean() instead. Added pre_action($action) and post_action($action) hooks instead which are called by Dh_Buildsystems::buildsystems_do(). * Builddir is handled via mkdir_builddir(), doit_in_buildddir(), clean_builddir() methods which buildsystems should call directly. Removed get_top* method, added get_rel2builddir_path(). * is_buildable() method renamed to is_auto_buildable() to reflect its purpose more. * ::perl_makefile renamed to ::perl_makemaker and which is based on ::makefile now. MakeMaker hack moved from ::makefile to ::perl_makemaker where it belongs (thanks for the tip). * Dh_Buildsystems refactored into a simple perl module rather than OO class and simplified a bit. * @BUILDSYSTEMS and is_auto_buildable() modified to 100% match historical order. TODO: user documentation (e.g. DH_AUTO_BUILDDIRECTORY and DH_AUTO_BUILDSYSTEM environment variables and common dh_auto_* options (--buildsystem and --builddirectory)). Current plugin inheritance hierarchy is like this: Buildsystem::perl_build -> Dh_Buildsystem_Basic <- Buildsystem::python_distutils ^ | Buildsystem::makefile <- Buildsystem::perl_makemaker ^ ^ ^ / | \ Buildsystem::autotools Buildsystem::cmake Buildsystem::python_distutils Signed-off-by: Modestas Vainius <modestas@vainius.eu>
* | code review, added commentsJoey Hess2009-04-10
| | | | | | | | | | I went through every line of the buildsystem implementation, and added numerous comments. Search for "XXX JEH" to find them.
* | Modular object-orientied buildsystem implementation.Modestas Vainius2009-04-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Dh_Buildsystems: 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. ----------------------------- ----------------------------- Dh_Buildsystem_Bases.pm: 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 Signed-off-by: Modestas Vainius <modestas@vainius.eu>
* | Add dpkg_architecture_value and sourcepackage to Dh_LibModestas Vainius2009-04-10
|/ | | | | | | | | Both these function are taken from dh_auto_configure. I believe they are useful enough to be in Dh_Lib (esp. dpkg_architecture_value()). The patch removes these funtions from dh_auto_configure too. Signed-off-by: Modestas Vainius <modestas@vainius.eu>
* export write_logJoey Hess2009-03-23
| | | | Avoids the ugly thunk in dh
* minor coding stlyeJoey Hess2009-03-23
|
* Add a global --remaining-packages option.Modestas Vainius2009-03-23
| | | | | | | | 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). Signed-off-by: Modestas Vainius <modestas@vainius.eu>
* fix corner caseJoey Hess2009-03-20
| | | | | If DH_INTERNAL_OPTIONS does not specify any packages, we don't want to exclude them all!
* remove dead codeJoey Hess2009-03-20
| | | | | This case can never happen, because code in Dh_Getopt makes the same check earlier.
* Fix calling the same helper for separate packages in the override of dh ↵Joey Hess2009-03-20
| | | | | | | | | | | | 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.
* Compatability level 4 is now deprecated.Joey Hess2009-03-07
|
* Merge branch 'dh_overrides'Joey Hess2009-02-27
|\ | | | | | | | | | | Conflicts: Debian/Debhelper/Dh_Getopt.pm debian/changelog
| * fix option parsing sideportJoey Hess2009-02-27
| |
| * dh override targetsJoey Hess2009-02-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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) Conflicts: Debian/Debhelper/Dh_Getopt.pm Debian/Debhelper/Dh_Lib.pm debian/changelog dh
* | Improve error messages when child commands fail.Joey Hess2009-02-21
| |
* | dh override targetsJoey Hess2009-02-16
| | | | | | | | | | | | | | | | | | | | * 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.
* | Ignore unknown options in DH_OPTIONS. Debhelper will always ignore such ↵Joey Hess2008-12-14
| | | | | | | | 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.)
* | fix wording for when there are multiple optionsJoey Hess2008-10-21
| |
* | Move many command-specific options to only be accepted by the command that ↵Joey Hess2008-10-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | uses them. Affected options are: -x, -r, -R, -l, -L, -m, --include-conffiles, --no-restart-on-upgrade, --no-start, --restart-after-upgrade, --init-script, --filename, --flavor, --autodest, --libpackage, --add-udeb, --dpkg-shlibdeps-params, --dpkg-gencontrol-params, --update-rcd-params, --major, --remove-d, --dirs-only, --keep-debug, --version-info, --list-missing, --fail-missing, --language, --until, --after, --before, --remaining, --with * 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.
* | Allow individual debhelper programs to define their own special options by ↵Joey Hess2008-10-21
|/ | | | passing a hash to init(), which is later passed on the Getopt::Long. Closes: #370823
* dh_installinit: Add --restart-after-upgrade, which avoids stopping a daemon ↵Joey Hess2008-05-08
| | | | in the prerm, and instead restarts it in the postinst, keeping its downtime minimal. Since some daemons could break if files are upgraded while they're running, it's not the default. It might become the default in a future (v8) compatability level. Closes: #471060
* dh addon interfaceJoey Hess2008-05-04
| | | | | | | | | | | | * dh: Add an interface that third-party packages providing debhelper commands can use to insert them into a command sequence. (See dh(1), "SEQUENCE ADDONS".) * dh: --with=foo can be used to include such third-party commands. So, for example, --with=cli could add the dh_cli* commands from cli-common. * Moved python-support special case out of dh and into a python-support sequence addon. --with=python-support is enabled by default to avoid breaking backwards compatability.
* Convert copyright file to new format.Joey Hess2008-04-30
|
* improve error furtherJoey Hess2008-04-29
|
* Add missing $! to error message when the log can't be opened.Joey Hess2008-04-29
|
* dh_prep: New program, does the same as dh_clean -k (which will be deprecated ↵Joey Hess2008-04-23
| | | | later).
* don't log dh runsJoey Hess2008-04-23
|
* updatesJoey Hess2008-04-23
|
* dh is now workingJoey Hess2008-04-23
| | | | | | And debian/rules uses it. Sweet!
* initial version of dh, with option parsing and sequences in placeJoey Hess2008-04-23
|
* New v7 mode, which only has one change from v6, and is the new recommended ↵Joey Hess2008-04-23
| | | | | | | | | | | default. * New v7 mode, which only has one change from v6, and is the new recommended default. * dh_install: if --sourcedir is not specified, first look for files in debian/tmp, and then will look in the current directory. This allows dh_install to interoperate with dh_auto_install without needing any special parameters.
* Record debhelper commands that successfully finish in a per-package log file.Joey Hess2008-04-23
|
* * The order of dependencies generated by debhelper has been completly randomJoey Hess2008-03-04
| | | | (hash key order), so sort it. Closes: #468959
* * dh_strip: Improve the idempotency fix put in for #380314.Joey Hess2008-01-24
| | | | * dh_strip: The -k flag didn't work (--keep did). Fix.
* r2033: * Add --ignore option. This is intended to ease dealing with upstreamjoeyh2007-09-30
| | | | | | | | tarballs that contain debian directories, by allowing debhelper config files in those directories to be ignored, since there's generally no good way to delete them out of the upstream tarball, and they can easily get in the way if upstream is using debian/ differently than the Debian maintainer.