| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
This is really atrocious, but IIRC the order pythons are run in matters,
so the earlier mangling of @python_requested must remain, and so unmangle
it here.
|
| |
|
|
|
|
| |
installed, don't trust the presense of the executable, as a python2.X-minimal package may provide it while not having distutils installed. Closes: #683557
python hate increasing..
|
| |
|
|
| |
#683551 Thanks, Clint Byrum
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
python-dbg is run it does not win and result in scripts having it in the shebang line. Closes: #589759
(cherry picked from commit 865e6266a5eaae81004bf530bc23da1c3fdc10b1)
Conflicts:
debian/changelog
|
| |
|
|
|
|
|
|
|
|
|
|
| |
when python-dbg is run it does not win and result in scripts having it in the shebang line. Closes: #589759"
This reverts commit 865e6266a5eaae81004bf530bc23da1c3fdc10b1.
Conflicts:
debian/changelog
Too late for 8.0.0 since testing is frozen. Will put back in later.
|
| |
|
|
| |
python-dbg is run it does not win and result in scripts having it in the shebang line. Closes: #589759
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
| |
--force allows doing so
|
| | |
|
| |
|
|
|
|
| |
This command will prevent distutils from attempting to determine
whether a file should be installed based on the timestamp of the
to-be-overwritten file.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
To allow backports of debhelper we don't pass
--install-layout=deb to 'setup.py install` for those Python
versions where the option is ignored by distutils/setuptools.
|
| | |
|
| |\
| |
| |
| |
| | |
Conflicts:
Debian/Debhelper/Buildsystem/python_distutils.pm
|
| | | |
|
| |/ |
|
| |
|
|
|
| |
The default dbg interpreter can be installed by
various build-deps, check them all.
|
| |\
| |
| |
| |
| | |
Conflicts:
Debian/Debhelper/Buildsystem/python_distutils.pm
|
| | | |
|
| | | |
|
| | |\ |
|
| | | | |
|
| | |/
|/|
| |
| |
| | |
Python dbg interpreters are only called if the
package build-depends on them.
|
| |/
|
|
|
|
|
| |
python_distutils buildsystem: Build for all supported Python
versions in case they're installed. Ensure that correct
shebangs are created by using `python' first during build
and install. Closes: #520834
|
| | |
|
| |
|
|
| |
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
|
|
| |
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
|
|
|
|
|
|
| |
Also add enforce_out_of_source_building() for clarity which does not
take any parameters. Now both have a clear name and no confusing
parameter combinations.
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| | |
|
| |
|
|
|
| |
Conflicts:
dh_auto_install
|
| |
|
|
|
|
|
|
|
|
|
| |
I'm reverting the documentation addition to try doing it
myself, more simply and less verbosely.
This reverts commit 962a2e10c930e3504ea1c0327be2fdf70d53023e.
Conflicts:
dh_auto.pod
|
| |
|
|
| |
Signed-off-by: Modestas Vainius <modestas@vainius.eu>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* dh_auto.pod -> dh_auto.7 - contains general information about dh_auto,
its features, build systems supported by default (the latter is injected by
man/dh_auto_pod script from Debian/Debhelper/Buildsystem/*.pm PODs via
placeholders (#PLACEHOLDER#))
* POD in Debian/Debhelper/Buildsystem/*.pm -> dh_auto_<buildsystem>.7 - build
system specific information.
* dh_auto_* -> dh_auto_*.1 - relatively shorty description of the specific
dh_auto_* program and build system specific info for that step injected from
Debian/Debhelper/Buildsystem/*.pm with man/dh_auto_pod script.
* man/dh_auto_pod $step - generates full dh_auto_$step POD (replaces
placeholders).
* man/dh_auto_pod - generates full dh_auto.pod (replaces placeholders).
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().
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Apparently, Distutils does out of source tree building by default.
* Default build directory is "$srcdir/build".
* --build-base command line option is ineffective (some even fail)
unless it is passed to the "build" command. However, if build-base is set in
the config file, all setup.py commands use it (build, install and clean).
That's a big flaw in Distutils design but it has been like this for a long
time. Therefore write a custom distutils cfg file in the build directory
to make build-base work. The best choice for config file path is
$HOME/.pydistutils.cfg (one of the paths Distutils reads) and setting $HOME
to the build directory.
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.
|
| |
|
|
|
| |
Shorten, remove duplicate verbiage, and list the characteristic file
of the build system.
|
| |
|
|
|
| |
This way the root of the class hierarchy has the same name as the directory
holding the classes.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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>
|
