path: root/Debian/Debhelper/
Commit message (Collapse)AuthorAge
* add commentJoey Hess2012-11-12
* Makefile: introduce PREFIX variableChristoph Junghans2012-11-12
* Make it possible to pass perl code to autoscript.Marcin Owsiany2012-09-09
| | | | | | | The shell-quoted sed code passed as parameter 4 is fragile (see Bug#665296). Make it possible to pass a sub that operates on each line via $_ instead. Also add a basic unit test for Dh_Lib, for now just with tests for autoscript.
* comment typoJoey Hess2012-03-26
* Revert avoid expanding shell metacharacters in sed call in autoscript(). It ↵Joey Hess2012-03-22
| | | | breaks dh_usrlocal and must be considered part of its interface. Added to interface documentation. Closes: #665263
* avoid expanding shell variables in sed stringJoey Hess2012-02-21
* spelingJoey Hess2012-01-15
* v9 doneJoey Hess2012-01-15
| | | | | | | | * Finalized v9 mode, which is the new recommended default. (But continuing to use v8 is also fine.) * It is now deprecated for a package to not specify a compatability level in debian/compat. Debhelper now warns if this is not done, and packages without a debian/compat will eventually FTBFS.
* Only enable executable config files in v9. The quality of file permissions ↵Joey Hess2011-12-09
| | | | in debian/ directories turns out to be atrocious; who knew?
* executable config files. bleh, arghJoey Hess2011-12-07
| | | | | | | | | | | | | | | | | | Debhelper config files may be made executable programs that output the desired configuration. No further changes are planned to the config file format; those needing powerful syntaxes may now use a programming language of their choice. In many bugs I see a tendency of users wanting debhelper configuration files to have their pet feature from some programming language. So I choose to short-circuit this process by taking it to its logical conclusion, and without the bother of developing a new language myself. [ Is this consistent with my boycott/disinterest in integrating features features first developed in Ubuntu? Yes. Instead of blocking the issue of multiarch needing variable expansions, I have stepped back and let anyone make whatever mess they desire while not forcing that mess on the rest of us. ]
* dh: Avoid compat deprecation warning before option parsing. Closes: #641361Joey Hess2011-09-12
* Tighten parsing of DEB_BUILD_OPTIONS.Joey Hess2011-09-09
| | | | | A future nostripexceptonfullmoon option seems unlikely, but sure, let's be strict. More importantly, let's reuse good code.
* Avoid writing debhelper log files in no-act mode. Closes: #640586Joey Hess2011-09-05
* dpkg-buildflags is only used to set environment in v9Joey Hess2011-08-06
| | | | | | To avoid re-breaking packages that were already broken a first time by dpkg-buildpackage unconditionally setting the environment, and unbroke it by unsetting variables in the rules file. (Example: numpy)
* Revert "Always respect DEB_${flag}_{APPEND,SET} envvars."Joey Hess2011-06-20
| | | | | | This reverts commit fcfcd1298f6ea1fcfb2b2b5a529303270aa800d9. Per Raphael's mail.
* Always respect DEB_${flag}_{APPEND,SET} envvars.Modestas Vainius2011-06-19
| | | | | | Do that even when dpkg-buildpackage modifies environment variables. Also document DEB_${flag}_{APPEND,SET} as recommended way to override standard build flags.
* In the unlikely case Dpkg::BuildFlags fails, don't do anything.Modestas Vainius2011-06-19
* Use Dpkg::BuildFlags module directly in set_buildflags().Modestas Vainius2011-06-19
| | | | | | | Dpkg::BuildFlags API is declared stable. It should be safe to use it directly rather than dpkg-buildflags wrapper. In addition, do not do any DEB_BUILD_OPTIONS=noopt handling in debhelper. Dpkg::BuildFlags already does it for us.
* dpkg-buildflags supportJoey Hess2011-06-14
| | | | | | | | * dh_auto_build, dh_auto_configure, dh: Set environment variables listed by dpkg-buildflags --export. Any environment variables that are already set to other values will not be changed. Closes: #544844 * Also, support DEB_BUILD_OPTIONS=noopt, by changing -O2 to -O0.
* Fix error message. Closes: #628053Joey Hess2011-05-27
* Add support for multiarch.Steve Langasek2011-03-12
| | | | | | | | | | | | | | Open compat level 9, which incompatibly changes dh_auto_configure behavior to set --libdir and --libexecdir to the multiarch directory path. This requires dpkg-dev 1.16.0 (not yet released) for the multiarch directory variable, so bump the dependency to this version. Also set a new substvar, misc:Pre-Depends, to multiarch-support, a virtual package provided by versions of eglibc that support the multiarch library paths at runtime; this needs to be a pre-dependency to ensure unpacked but not-yet-configured libraries can still be found during upgrades, so library packages converting to multiarch (i.e., switching to compat 9) will need to add this substitution by hand to debian/control.
* Improve handling of logging in override targetsJoey Hess2011-02-10
| | | | | | | | | | | | | | | Changes in 76ef1cbd64829ee4a5156a5fc4b887bcba6b974f broke --remaining-packages in override target. Now all debhelper commands run in the override target are marked as running as part of the override, and when the whole target is run, the log is updated to indicate that commands run during the override have finished. So, inside the override target, --remaining-packages will see the commands run as part of the target as having been run. Outside, if the target fails, dh won't see the commands run it it as having been run. Closes: #612828
* refactor cross command generationJoey Hess2011-02-08
* dh: Inhibit logging for commands run inside override targetsJoey Hess2010-11-02
| | | | | | | Note that only the overridden command is inhibited. I wanted to avoid a behavior change if a rules file runs other debhelper commands inside the target, and relies on the logging preventing them being run later on in the sequence.
* note that the hardcoded arg_max here is obsoleteJoey Hess2010-10-27
* In v8 mode, do not allow directly passing unknown options to debhelper ↵Joey Hess2010-05-23
| | | | commands. (Unknown options in DH_OPTIONS still only result in warnings.)
* Further reduce the number of calls to dpkg-architecture to zero, in a ↵Joey Hess2010-05-09
| | | | typical package with no explicit architecture mentions in control file or debhelper config files.
* typoJoey Hess2010-05-09
* cleanupsJoey Hess2010-05-09
* Drop one more call to dpkg-architecture. Closes: #580837 (Raphael Geissert)Joey Hess2010-05-09
* Memoize architecture comparisons in samearch, and avoid calling ↵Joey Hess2010-04-26
| | | | dpkg-architecture at all for simple comparisons not involving architecture wildcards. Closes:# 579317
* fix commentJoey Hess2010-04-08
* minor optimisationJoey Hess2010-03-01
* If neither -a or -i are specified, debhelper commands used to default to ↵Joey Hess2010-03-01
| | | | acting on all packages in the control file, which was a guaranteed failure if the control file listed packages that did not build for the target architecture. After recent optimisations, this default behavior can efficiently be changed to the more sane default of acting on only packages that can be built for the current architecture. This change is mostly useful when using minimal rules files with dh. Closes: #572077
* Fix warning about unknown options passed to commands in override targets.Joey Hess2010-01-04
| | | | | | | | | dh used DH_OVERRIDE_UNKNOWN_OPTIONS, which was too broad as it affected commands run via override targets and caused there to be no warning about unknown options. Now unknown options are only ignored when parsing DH_INTERNAL_OPTIONS and dh's own options.
* use foreach instead of for when looping thru arrayJoey Hess2009-11-19
* make error() throw a catchable error with dieJoey Hess2009-11-16
| | | | | exit cannot be caught with eval.. I used exit before because I thought it was cute for erorr() to call warning(). Silly.
* Adjust code to add deprecation warning for compatability level 4. (Man page ↵Joey Hess2009-11-12
| | | | already said it was deprecated.) Closes: #555899
* reduce amount of MAKEFLAGS cleaningJoey Hess2009-10-28
| | | | | | | | | | | Now clean_jobserver_makeflags will only remove --jobserver settings from MAKEFLAGS. This is simpler and easier to understand than the old behavior, which, if there was no --jobserver, removed all -j and --jobs, while leaving those when removing --jobserver. This relies on -j options passed to make overriding -j settings in MAKEFLAGS. So we don't need to clean those out, we can just override them.
* split get_make_jobserver_status into two functionsJoey Hess2009-10-28
| | | | | | | | | | | I disliked the complexity of the return values, and the boilerplate code that followed the two calls to the function, to clean/unset MAKEFLAGS. To solve both, I refactored it into two functions, one simply tests to see if a jobserver is specified but unavailable, while the other cleans/unsets MAKEFLAGS. This loses the ability to pull the jobs-N count out of MAKEFLAGS, but that was not currently used.
* move obscure function to EOFJoey Hess2009-10-28
* Support parallel building in makefile buildsystemModestas Vainius2009-10-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1) Add routine to Dh_Lib (used by dh and which is capable of detecting make jobserver and job control options from the MAKEFLAGS environment variable. It also generates and returns a clean up MAKEFLAGS from these options. 2) Add --parallel option to build system framework which allows source packages to specify that they support parallel building. Optional value for this option is the number of maximum parallel process to allow. However, the actual number of parallel process (if any) for the specific build is determined from DEB_BUILD_OPTIONS env variable as specified by Debian Policy. By default (no --parallel option) parallel is neither enabled nor disabled (depends on the external environment). However, dh may pass --parallel to dh_auto_* implicitly in case 4) described below. 3) Add parallel support for makefile buildsystem. This implementation forcefully starts a new make job server (or disables parallel) for the number of process requested. If --parallel was not passed to the build system at all, the build system will only clean up MAKEFLAGS from stale jobserver options to avoid pointless make warnings. 4) If dh detects that it is being run by dpkg-buildpackage -jX and it is NOT run with "+" prefix from debian/rules (i.e. jobserver is not reachable), it enables --parallel implicitly. This closes: #532805. Signed-off-by: Modestas Vainius <>
* consistently print whole failing command lineJoey Hess2009-10-19
* Allow dpkg-architecture to print errors to stderr. Closes: #548636Joey Hess2009-09-27
* -a == -sJoey Hess2009-09-01
| | | | | | | The -a flag now does the same thing as the -s flag, so debhelper users do not need to worry about using the -s flag when building a package that only builds for some architectures, and dh will also work in that situation. Closes: #540794
* Optimise -s handling to avoid running dpkg-architecture if the package is ↵Joey Hess2009-09-01
| | | | arch all.
* refactorJoey Hess2009-09-01
* minor code cleanup and optimisationJoey Hess2009-08-10
* Revert "Improvements in DH_OPTIONS handling and DH_AUTO_OPTIONS envvar support."Modestas Vainius2009-06-13
| | | | | | | | | | | | This mostly reverts commit f897611a77726655aea258af0c4d52a8ce759ebc. Remaining cosmetic changes (all functional changes have been reverted): * Refactoring of option string into split_options_string() sub (no semantic changes though). * Cosmetic change in Breaks testsuite.
* Improvements in DH_OPTIONS handling and DH_AUTO_OPTIONS envvar support.Modestas Vainius2009-06-08
| | | | | | | | | | | | | | * DH_AUTO_OPTIONS is like existing DH_OPTIONS, just only for dh_auto stuff. This also avoids "explosion" of separate DH_AUTO_* environment variables (i.e. exports in debian/rules) and encourages usage of dh_auto command line option names. DH_AUTO_OPTIONS is passed via "extra_args" to Dh_Lib::init() (API addition). * When splitting options from DH_OPTIONS and its flavours, allow arguments to include whitespaces if they are escaped with backslash (\) (see split_options_string()). Document this in debhelper.pod. * Short option for --buildsystem is -c (aka class). * Provide API to cancel option specs from default debhelper options. It will be used in the feature.