path: root/Debian/Debhelper/Buildsystem/
Commit message (Collapse)AuthorAge
* cmake: Configure with -DCMAKE_BUILD_TYPE=None Closes: #701233Joey Hess2013-12-05
* cmake: Configure with -DCMAKE_BUILD_TYPE=RelWithDebInfo Closes: #701233Joey Hess2013-02-24
| | | | | I'm told this only avoids building with -O3 -DNDEBUG, a change which should have no potential for breaking anything.
* releasing version 9.20120419Joey Hess2012-04-17
* cmake: Only pass CPPFLAGS in CFLAGS in v9.Joey Hess2012-04-17
* cmake: Pass CPPFLAGS in CFLAGS. Closes: #668813 Thanks, Simon Ruderich for ↵Joey Hess2012-04-17
| | | | the patch and for verifying no affected package is broken by this change.
* Add support for running tests in parallel to the cmake build system.Modestas Vainius2011-08-05
| | | | | | | | | | | 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.
* dh_auto_configure: If there is a problem with cmake, display the CMakeCache.txt.Joey Hess2011-06-24
* Fix deep recursive in cmake::test().Modestas Vainius2009-11-21
* cmake build+ steps need Makefile.Modestas Vainius2009-11-19
| | | | | | The condition is not what dh_auto_* 7.0.x would have done. The patch makes auto-selection to pass through if Makefile was not created. This problem is not very dangerous though.
* comment mungingJoey Hess2009-11-18
* Improve build system auto-selection processModestas Vainius2009-11-18
| | | | | | | | | | | | | | | 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 <>
* Enable verbose ctest output on test failureModestas Vainius2009-11-16
| | | | | | | | | | | | When test fails, enable verbose ctest output. This allows to get more details on a test failure from the build logs. Auto-select cmake in further steps only if cmake was run in configure step. CMake writes CMakeCache.txt to build directory when it is run. Depend on the presence of this file for auto-selection in build, test, install and clean steps. Signed-off-by: Modestas Vainius <>
* Enable verbose ctest output on test failureModestas Vainius2009-11-12
| | | | | | | When test fails, enable verbose ctest output. This allows to get more details on a test failure from the build logs. Signed-off-by: Modestas Vainius <>
* cmake: Avoid forcing rpath off as this can break some test suites. It gets ↵Joey Hess2009-08-01
| | | | stripped by cmake at install time. Closes: #538977
* Bug fix: pass extra command line arguments to cmake.Modestas Vainius2009-06-30
| | | | Signed-off-by: Modestas Vainius <>
* Rename enforce_out_of_source_building() to prefer_Modestas Vainius2009-06-30
| | | | | | | | 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 <>
* misc minor changesJoey Hess2009-06-29
* Revert "Update dh_auto documentation."Joey Hess2009-06-28
| | | | | | | | | | | I'm reverting the documentation addition to try doing it myself, more simply and less verbosely. This reverts commit 962a2e10c930e3504ea1c0327be2fdf70d53023e. Conflicts: dh_auto.pod
* Update dh_auto documentation.Modestas Vainius2009-06-18
| | | | | | | | | | | | | | | | | * 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 <>
* Do not explicitly repass env. variables {C,CXX,LD}FLAGS to cmake.Modestas Vainius2009-06-18
| | | | | | | Apparently, cmake itself reads values of those environment variables and uses them accordingly. There is no need to repass them via -DCMAKE_{C,CXX,LD}_FLAGS. Signed-off-by: Modestas Vainius <>
* Less code in the build system classes to call enforce_out_of_source_building().Modestas Vainius2009-06-18
| | | | Signed-off-by: Modestas Vainius <>
* Some cosmetic changes in the comments and strings.Modestas Vainius2009-06-17
| | | | | | | | * buildsystem -> build system * dh_auto build system -> debhelper build system * plugin -> class * a few rewording changes in the comments. * Enhance python_distutils::DESCRIPTION().
* Enforce out of source building in soft mode for cmake.Modestas Vainius2009-06-13
| | | | | | | | | Technically, cmake supports in source builds, they are simply not recommended. However, if the user insists and explicitly specifies the build directory that is equal to the source directory, allow this (aka soft mode). Signed-off-by: Modestas Vainius <>
* Implement source directory switching support (Closes: #530597).Modestas Vainius2009-06-09
| | | | | | | | * 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.
* Use term "out of source" rather than "outside source".Modestas Vainius2009-06-08
| | | | | | * "out of source" or "out of source tree" seems to be more popular term to describe building in the builddir. * Avoid using hyphens in both "out of source" and "in source" terms.
* Use the term "build step" instead of "build action" everywhere in the source.Modestas Vainius2009-06-08
| | | | | 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.
* reword descriptionsJoey Hess2009-04-20
| | | | | Shorten, remove duplicate verbiage, and list the characteristic file of the build system.
* use $this rather than $selfJoey Hess2009-04-20
* let's write class, not clsJoey Hess2009-04-20
* debhelper modular buildsystems (try 3).Modestas Vainius2009-04-15
| | | | | | | | | | | | | | | * New feature - when listing buildsystems, list their status too (auto/specified). * renamed to * 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 <>
* update and remove XXX commentsJoey Hess2009-04-14
* Modular object-orientied buildsystem implementation (try 2).Modestas Vainius2009-04-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Major changess: * Dh_Buildsystem_Option dropped and Dh_Buildsystem_Chdir functionality partitially merged into Dh_Buildsystem_Basic. renamed to 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 <>
* code review, added commentsJoey Hess2009-04-10
| | | | | I went through every line of the buildsystem implementation, and added numerous comments. Search for "XXX JEH" to find them.
* Modular object-orientied buildsystem implementation.Modestas Vainius2009-04-10
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. ----------------------------- ----------------------------- 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 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 -- 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. and its derivatives: and 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 $ ./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 <>