| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
Do that even when dpkg-buildpackage modifies environment variables. Also
document DEB_${flag}_{APPEND,SET} as recommended way to override standard build
flags.
|
|\
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
targets
This assumes that all implicit rules file targets are owned by dh, so
it can just assume an implicit target can be optimized away to the commands
in its sequence.
I suppose this would break:
build:
dh build
install: build
dh install
binary-%: install
my-binary-builder-$@
my-binary-builder-arch:
echo "whee! I did something pointlessly complicated with make!"
dh binary-arch
my-binary-builder-indep:
dh binary-indep
But I can't imagine anyone does this, at least with a probability of 1 in
ten thousand, so hopefully it doesn't break any existing packages. :)
|
| |
| |
| |
| |
| |
| |
| | |
Reorder code so sequences can all be built before addons are loaded, so
addon interface can always affect all commands in any sequences. This fixes
a bug in the previous patch, where addons could not influence dh_testdir
and dh_testroot.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Callers overriding build targets will need to configure by hand or by
calling dh_auto_configure, which should be the status quo. And moving
dh_auto_configure to build (and build-arch and build-indep) will not
make it run twice AFAICS (except for the edge case when it already did:
debian/rules build-arch build-indep)
|
| |
| |
| |
| |
| | |
These calls are no-ops, unless explicit targets exist, and in that case
later code rewrites the build and install sequences to include them.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The build and install rules run a minimal sequence if the build-arch or
build-indep, or install-arch or install-indep targets, respectively,
are present in debian/rules. The purpose is to not do work ahead of
time, such as building before the build-arch or build-indep targets are
built, which could potentially lead to misbuilds. If the targets are
not defined, the sequences may be run directly which is faster due to
being able to run the arch and indep commands together.
|
|/
|
|
|
|
|
|
|
| |
Rather than dh sequences containing dependent sequences within
themselves, invoke the sub-sequence via debian/rules to permit
overriding and customisation using the policy-defined debian/rules
targets.
Signed-off-by: Roger Leigh <rleigh@debian.org>
|
| |
|
| |
|
|
|
|
| |
#604727
|
|
|
|
| |
overridden command. Closes: #613418
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
running sequence"
This reverts commit c685546d18606fafee2ad9d3a1cb3d90dd7e9d5e.
Caused extra work, and possible FTBFS conditions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add %sequence_deps and invoke recursively prior to examining logs and
running commands in sequence. The supplied dependencies are equivalent
to the following make rules:
build: build-arch build-indep
install: install-arch install-indep
install-arch: build-arch
install-indep: build-indep
binary: binary-arch binary-indep
binary-arch: install-arch
binary-indep: install-indep
In the existing dh command sequences, the binary sequences all included
the corresponding install sequence commands, and in turn the install
sequences all included the corresponding build commands. While this
works, it has a major deficiency. If the "binary" sequence is run, it
will not run the "build" target in debian/rules. This leads to a
situation where building with dpkg-buildpackge, which would typically
invoke "debian/rules build" followed by "debian/rules binary-arch"
and/or "debian/rules debian-indep" may do something different than
just invoking "debian/rules binary" or "dh binary" because the build
target in debian/rules is effectively bypassed. This applies equally
to the -arch and -indep sequence variants.
This change eliminates the duplicated sequence commands, and instead
invokes the appropriate target(s) in debian/rules, as specified in the
%sequence_deps hash. In the common case, the dh sequence by the same
name will be called, so the behaviour is identical. However, this
provides a means to utilise all of the policy-specified targets, plus
the install targets and extend them with additional dependencies and
commands, while still allowing full use of dh and giving identical
behaviour whether dh or debian/rules targets are used.
Signed-off-by: Roger Leigh <rleigh@debian.org>
|
|
|
|
|
|
| |
consistency
Signed-off-by: Roger Leigh <rleigh@debian.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sequences
The existing binary-arch and binary-indep sequences depend upon these
new sequences, leading to the following possible orders:
binary → install → build
binary-arch → install-arch → build-arch
binary-indep → install-indep → build-indep
This is the logical dependency ordering of the sequences; the actual
order is of course in reverse so that build is followed by install
and binary.
Signed-off-by: Roger Leigh <rleigh@debian.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
$(findstring) can match partial strings and so is unreliable when a
package builds several binary packages and one package contains the
name of another package within its name. In these cases,
$(findstring) can return a partial match which leads to problems
(performing unwanted actions which could lead to build failure, for
example).
$(filter) matches the entire string in the wordlist, so is a
reliable replacement for $(findstring).
Signed-off-by: Roger Leigh <rleigh@debian.org>
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
As advised in man(1), always use: B<bold text> type exactly as shown.
I<italic text> replace with appropriate argument.
s/debian/Debian/ if needed. s/ / / also.
s/perl/Perl/ s/python/Python/ and s/emacs/Emacs/ too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This avoids ambiguities when parsing options to be passed on to debhelper
commands. (See #570039)
In the end, the idea of putting the debhelper command options after --
seemed to need too much knowledge about whether an option like
--buildsystem is a dh option or a command option.
I did consider making no change.. The ambiguities this eliminates are
small. But it seemed worth simplifying dh's option parser, and only about
1/6th of calls to dh in the archive don't put the sequence first already.
(Docs have shown that as the right thing to do for some time.)
|
|
|
|
| |
commands. (Unknown options in DH_OPTIONS still only result in warnings.)
|
| |
|
|
|
|
|
|
|
| |
joeyh: debhelper has an undocumented variable with INTERNAL in its name.
People keep trying to use it. Why?
liw: debhelper is magic. magic is power derived from secrets. secrets are
desireable. solution: document it. :)
|
| |
|
| |
|
|
|
|
| |
"-Bpython-support". Closes: #570039
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
* Add -O option, which can be used to pass options to commands, ignoring
options that they do not support.
* dh: Use -O to pass user-specified options to the commands it runs.
This solves the problem with passing "-Bbuild" to dh, where commands
that do not support -B would see a bogus -u option. Closes: #541773
(It also ensures that the commands dh prints out can really be run.)
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
| |
1) Detect if target is noop when parsing debian/rules.
2) If override target is noop, do not call make for it.
|
|
|
|
| |
several commands. Closes: #560600
|
| |
|
| |
|
|
|
|
|
| |
I renamed --parallel to --max-parallel to clarify that it doesn't enable
parallelism, but only controls how much of it is allowed.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|