| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
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)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Pass appropriate -jN option to ctest (via ARGS variable in the Makefile) to
enable support for running tests in parallel. Similarly to makefile build
system, ctest -j1 mode is enforced even when parallel mode in debhelper is not
explicitly enabled.
Unlike make, CTest does not have "unlimited parallel" setting (-j implies -j1).
So in order to simulate unlimited parallel, allow to fork a huge number of
threads instead.
|
| | |
|
| |
|
|
|
|
| |
Assume that the package can be cleaned (i.e. the build directory can be
removed) as long as it is built out-of-source tree and can be configured. This
is useful for derivative buildsystems which generate Makefiles.
|
| |
|
|
| |
override targets instead.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If a rules file has a custom install or binary target, those targets
still need to explicitly depend on the build target. Unless dh is used
in such a target (which it probably is of course).
It's not possible to avoid the need for those dependencies. A rules file
with a hand-written binary target simply does not run dh, so dh can
do nothing to help it run the build target.
Reword the docs to not give the wrong impression that dh somehow
magically makes that work.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with a rules file with an explict build target. Closes: #634784
This hack was necessary back when dh ran each target, and so recursively
invoked itself. If debian/rules binary ran debian/rules binary-arch ran
debian/rules install-arch ran debian/rules build-arch, then debhelper
commands would be running with -a throughout, and so for debian/rules
binary-indep it would have to re-run all the commands with -i. The hack
avoided this extra work (and expecially dh_auto_configure running twice) by
first running the common commands without -i or -a and only then following
through with running the explicit per-arch targets, which didn't run many
(if any) additional commands.
But now dh does not run implicit targets, so (unless targets
are explicit), it will instead just construct a sequence of debhelper
commands to run directly, and so the -a flag is avoided.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Also simplified a lot by not special-casing the base case, at the cost of
always forking once.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Implement support for parallel deb builds, when DEB_BUILD_OPTIONS has
parallels=N - limiting the number of forked processes to N.
Requested-By: Kari Pahula <kaol@debian.org>
Signed-Off-By: Gergely Nagy <algernon@madhouse-project.org>
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
--buildsystem=qmake_qt4. Closes: #566840
There is that build system option patch that I suckily never applied,
and could be used here.. but this is at its core a different build system,
and so handling it as such makes the most sense.
It may make sense to have a qmake_qt3 build system, but perhaps QT 3
will instead just go away. I considered just waiting, but this is an easy
fix. ;)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
dh_pysupport has started emitting a deprecation warning, which is
very annoying since it clutters every build that uses dh -- even builds
where it doesn't do anything. Since there is not just a dh_python2, but
also a dh_python3 waiting in the wings, this is clearly too volatile
a situation for dh to try to support further.
I considered making dh_python detect and run the right dh_python[23] helper
-- a python helper helper as it were -- but 70-odd packages still use that
command.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This reverts commit fcfcd1298f6ea1fcfb2b2b5a529303270aa800d9.
Per Raphael's mail.
|
| | |
|
| |
|
|
|
|
| |
Do that even when dpkg-buildpackage modifies environment variables. Also
document DEB_${flag}_{APPEND,SET} as recommended way to override standard build
flags.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Conflicts:
dh
|
| | |
| |
| |
| |
| |
| |
| |
| | |
* 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.
|
| |\|
| |
| |
| |
| |
| | |
Conflicts:
debhelper.pod
debian/changelog
|
| | |
| |
| |
| |
| |
| |
| | |
--libexecdir when using autoconf. Closes: #541458
Fixed rleigh's patch to be more correct in the edge case where there is
a non-multiarch dpkg (ie, backports).
|
| | | |
|
| | |
| |
| |
| |
| | |
Appending @_ to a string appends the array length rather than
the array contents, so join with separating whitespace.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The makefile parse causes dh to be run recursively.
Before, dh would just immediatly fail with "unknown sequence", but
now it has to run the makefile parse to calculate the sequences, so an
earlier bailout is needed.
|
| | |
| |
| |
| |
| |
| | |
An empty explicit target in debian/rules should still be run,
to run its dependencies, and allow defining empty targets in order to
skip running what's nornally done by a sequence.
|
