| Commit message (Collapse) | Author | Age |
|
|
|
| |
#578805
|
|
|
|
| |
(at the end naturally)
|
|
|
|
|
|
|
|
|
| |
This patch adds --parallel option that enables parallel builds and does not
impose limits on maximum concurrent processes. --max-parallel (that implies
--parallel) can be used to specify that maximum limit.
Also make necessary adjustments to debhelper.pod and buildsystem_tests for
this option.
|
|
|
|
|
| |
$max is about upper limit. Make algorithm reflect that.
(cherry picked from commit 62d7dc07b97a12912cfe08483c6fb244161224f5)
|
|
|
|
| |
(cherry picked from commit 11b0b2483302f8694d8c6a76c73df1eefca7ad1f)
|
|
|
|
| |
enabled by using the --max-parallel option. This was necessary because some buildds build with -j2 by default.
|
| |
|
|
|
|
|
|
| |
In order to avoid code duplication, auto-selection code has been refactored
into separate subroutine autoselect_buildsystem(). Both load_buildsystem() and
buildsystem_list() use it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch alters semantics of check_auto_buildable() a bit. Now it can
also indicate if the source has already been partitially built with the
build system and if so, such build system may be auto-selected over a less
specific its parent (in the inheritance tree) even if the latter is earlier
in the @BUILDSYSTEMS array.
However, this still leaves a requirement that a derivative build system
must not do anything that may break packages of the parent build system.
Otherwise, introduction of a new derivative build system might break
packages which already had that build system implemented via overrides...
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
|
|
|
|
|
|
|
|
| |
dpkg-buildpackage -j sets DEB_BUILD_OPTIONS=parallel=-1. Policy does not
cover this but the intent is to allow unlimited parallel jobs.
Also, there is no longer any way for parallel to be set to undef, so remove
code to handle that.
|
| |
|
|
|
|
|
| |
I renamed --parallel to --max-parallel to clarify that it doesn't enable
parallelism, but only controls how much of it is allowed.
|
|
|
|
| |
Use a function to set the value rather than post-processing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) Add routine to Dh_Lib (used by dh and makefile.pm) 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 <modestas@vainius.eu>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
I'm unsure why we need this complication. Perl modules are allowed to
install man pages documenting the module, if it really needs documentation.
This reverts commit 49b64c7852744f54250121b1c60544e1f5de70b6.
|
| |
|
|
|
|
|
|
|
|
| |
I previously used "built-in debhelper build system" or "default debhelper build
system" for those shipped with debhelper. Now it is "standard debhelper build
system".
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
|
|
|
| |
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
|
|
|
|
|
|
|
| |
* buildsystem -> build system
* dh_auto build system -> debhelper build system
* plugin -> class
* a few rewording changes in the comments.
* Enhance python_distutils::DESCRIPTION().
|
|
|
|
|
|
|
|
| |
Displays POD of the (auto)selected build system. It should be useful to get
more information about third party build systems. Implementation uses
perldoc whenever possible.
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
|
|
|
| |
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* New short switches:
-D = --sourcedirectory
-B = --builddirectory
-S = --buildsystem
* Drop DH_AUTO_BUILD* environment variables (reintroduced due to revert).
* Adjust test suite.
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 Dh_Buildsystems.pm.
Breaks testsuite.
|
| |
|
|
|
|
|
|
|
|
| |
* Reorder $system and $step arguments to match create_buildsystem_instance()
order (less confusion).
* Pass arbitrary @_ from load_buildsystem() to create_buildsystem_instance().
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Auto-setting is_buildable flag in base constructor was pointless
and broken by design because:
- is_buildable = check_auto_buildable() used to be called *before*
constructor of the derivative class could call enforce_* methods. The
result of check_auto_buildable() might change after calling enforce_*
methods (in case check_auto_buildable() use get_buildpath() tests).
- it isn't used widely. Refactor those a few places.
* Due to above, 'build_step' does not need to be passed to the Buildsystem
anymore. Remove it from code.
* As a result of is_buidable removal, move warning of
enforce_in_source_building() to pre_building_step(). It caused unnecessary
noise when the object was constructed during test. It belongs to
pre_building_step stage anyway.
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
|
|
|
| |
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
|
|
|
|
|
|
|
| |
* New optional option --sourcedirectory/-d.
* New Buildsystem API methods for getting source directory/path
(since sourcedir may no longer be topdir), source 2 build
directory convertions, doit_in_sourcedir() etc.
* clean_builddir() -> rmdir_builddir() rename.
|
|
|
|
|
|
|
|
|
| |
* Implement a new sub in Dh_Buildsystems (load_all_buildsystems()) which
dynamically tries to find all buildsystem class files in perl module
directories (@INC) and clearly marks third party buildsystems as such.
* Use this sub for listing buildsystems so now --list easily helps a user
discover *all* buildsystem classes installed on his/her system clearly
separating built-in ones from third party ones.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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.
|
|
|
|
|
| |
I'm going to use this new term in documentation. I have never liked "action"
in this context, just couldn't think of anything better.
|
|
|
|
|
| |
It seems bette to use the more specific name in case we later want a
separate module for automake.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
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).
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
I went through every line of the buildsystem implementation,
and added numerous comments. Search for "XXX JEH" to find them.
|
|
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>
|