summaryrefslogtreecommitdiff
path: root/Debian
Commit message (Collapse)AuthorAge
* New short switches for buildsystem stuff, drop envvarsModestas Vainius2009-06-13
| | | | | | | | | | | | | * 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>
* Revert "Improvements in DH_OPTIONS handling and DH_AUTO_OPTIONS envvar support."Modestas Vainius2009-06-13
| | | | | | | | | | | | 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.
* Use another root directory in _rel2rel.Modestas Vainius2009-06-13
| | | | | | | Previous one caused test "_rel2rel no4" to fail. Also add a new test for _canonpath and two new tests for _rel2rel (related to "." handling). Signed-off-by: Modestas Vainius <modestas@vainius.eu>
* 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 <modestas@vainius.eu>
* Drop special handling for build directory ./path.Modestas Vainius2009-06-13
| | | | | | | | | Now build directory is always relative to the top directory (including default build directory) regardless what source directory is. However, if the build directory is not specified, it defaults to the source directory (aka in source building). Signed-off-by: Modestas Vainius <modestas@vainius.eu>
* Merge branch 'master' into buildsystemsJoey Hess2009-06-12
|\ | | | | | | | | | | Conflicts: Debian/Debhelper/Dh_Getopt.pm debian/changelog
| * Allow command-specific options to be passed to commands via dh without ↵Joey Hess2009-06-12
| | | | | | | | causing other commands to emit a getopt warning or deprecation message.
* | shouldn't need undef hereJoey Hess2009-06-12
| |
* | Ensure make doesn't print directories when checking for target existance.Modestas Vainius2009-06-11
| | | | | | | | | | | | | | | | | | | | Whenever make is run with --print-directory option, make -C sometimes print Entering/Leaving directory messages to stdout even with -s in effects This breakes a check for target existance as it relies on make printing nothing when target does not do anything. Hence explicitly pass --no-print-directory to make to avoid it. Signed-off-by: Modestas Vainius <modestas@vainius.eu>
* | Reorder load_buildsystem arguments and pass @_ through it.Modestas Vainius2009-06-11
| | | | | | | | | | | | | | | | * 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>
* | Make perl_makemaker work properly when in source building is enforced.Modestas Vainius2009-06-11
| | | | | | | | | | | | | | | | | | | | | | This is backwards compatible (with << 7.3) until build, test and clean steps are not reimplemented in the backwards compatibility breaking way. However, this is absolutely necessary for enforce_in_source_building() to work in corner cases (when build directory is set) in build, test and clean steps as the next class (makefile) does not enforce it. makefile will fail as it will look for Makefile in the build directory rather than the source directory. Signed-off-by: Modestas Vainius <modestas@vainius.eu>
* | Get rid of is_buildable and build_step flags. Broken by design.Modestas Vainius2009-06-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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>
* | Refactor build directory setting into separate method and solve a few bugs.Modestas Vainius2009-06-11
| | | | | | | | | | | | | | | | | | | | | | | | | | * Move setting of new build directory from constructor to _set_builddir() method including detection if directory (current or source) it should be relative to. * Even if a new build directory was specified, detect if it matches the source directory and unset it in such a case. * Use _set_builddir() in enforce_out_of_source_tree() methods. Previous implementation didn't handle default build directory properly (i.e. relativeness to current or source directory). Signed-off-by: Modestas Vainius <modestas@vainius.eu>
* | Remove empty build directory parent dirs (up to source directory) too.Modestas Vainius2009-06-11
| | | | | | | | | | | | | | When rmdir_building(), if build directory has 2 or more levels, empty parent dirs should also be deleted until source directory level. Signed-off-by: Modestas Vainius <modestas@vainius.eu>
* | Rename {pre,post}_step to {pre,post}_building_step.Modestas Vainius2009-06-11
| | | | | | | | Signed-off-by: Modestas Vainius <modestas@vainius.eu>
* | autoconf uses a couple of Dh_Lib functions.Modestas Vainius2009-06-11
| |
* | 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.
* | --list all buildsystems (including all 3rd party ones) dynamically.Modestas Vainius2009-06-08
| | | | | | | | | | | | | | | | | | * 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.
* | Improvements in DH_OPTIONS handling and DH_AUTO_OPTIONS envvar support.Modestas Vainius2009-06-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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.
* | 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.
* | merge masterJoey Hess2009-05-14
|\|
* | Merge branch 'master' into buildsystemsJoey Hess2009-05-14
|\| | | | | | | | | | | Conflicts: debian/changelog dh_auto_configure
| * Support debian/foo.os files to suppliment previous debian/foo.arch file ↵Joey Hess2009-05-12
| | | | | | | | support. Closes: #494914 (Thanks, Aurelien Jarno)
* | Merge branch 'master' into buildsystemsJoey Hess2009-05-11
|\| | | | | | | | | Conflicts: dh_auto_configure
* | incorporate create_packlist=0 fix from masterJoey Hess2009-05-11
| |
* | Merge branch 'master' into buildsystemsJoey Hess2009-05-11
|\| | | | | | | | | | | Conflicts: debian/changelog dh_auto_configure
| * Close COMPAT_IN filehandle. Closes: #527464Joey Hess2009-05-07
| |
* | rename autotools to autoconfJoey Hess2009-04-20
| | | | | | | | | | It seems bette to use the more specific name in case we later want a separate module for automake.
* | unimportant code changesJoey Hess2009-04-20
| |
* | remove verbose_print of buildsystem selection detailsJoey Hess2009-04-20
| | | | | | | | | | | | | | | | | | 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.
* | reformat listJoey Hess2009-04-20
| | | | | | | | | | 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).
* | reword descriptionsJoey Hess2009-04-20
| | | | | | | | | | Shorten, remove duplicate verbiage, and list the characteristic file of the build system.
* | factor out a buildsystems_listJoey Hess2009-04-20
| |
* | rename Dh_Buildsystem to BuildsystemJoey Hess2009-04-20
| | | | | | | | | | This way the root of the class hierarchy has the same name as the directory holding the classes.
* | use $this rather than $selfJoey Hess2009-04-20
| |
* | let's write class, not clsJoey Hess2009-04-20
| |
* | remove _mkdir, use mkdir -pJoey Hess2009-04-20
| | | | | | | | | | | | | | | | | | | | | | | | | | _mkdir is not necessary, because mkdir's error messages are good enough if a file by the name of the directory exists ("cannot create directory: File exists"), or if a file is where the parent directory should be ("cannot create directory: Not a directory") Using mkdir -p seems useful, in case someone wants a deeply nested builddir. This also changes the return value of mkdir_builddir, but nothing currently tests it.
* | remove discussionJoey Hess2009-04-20
| |
* | removal of comments I'm satisfied withJoey Hess2009-04-15
| |
* | debhelper modular buildsystems (try 3).Modestas Vainius2009-04-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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>
* | more commentsJoey Hess2009-04-14
| |
* | more commentsJoey Hess2009-04-14
| |
* | more commentsJoey Hess2009-04-14
| |
* | 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. 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>
* | 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. ----------------------------- ----------------------------- 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>
* | Add dpkg_architecture_value and sourcepackage to Dh_LibModestas Vainius2009-04-10
|/ | | | | | | | | Both these function are taken from dh_auto_configure. I believe they are useful enough to be in Dh_Lib (esp. dpkg_architecture_value()). The patch removes these funtions from dh_auto_configure too. Signed-off-by: Modestas Vainius <modestas@vainius.eu>
* export write_logJoey Hess2009-03-23
| | | | Avoids the ugly thunk in dh