my ($action)=@_;
# Handle configure; the rest - next class
- # XXX JEH
- # Currently, if there is a configure script, and dh_auto_build
- # is run w/o dh_auto_configure having been run, there's no
- # Makefile, so the next class's detection routine also fails, and
- # presumably all do, resulting in dh_auto_build doing nothing
- # and silently "succeeding".
- # So, why not always test for configure? Then, for ! configure
- # actions, it would use the methods inherited from its parent
- # class. In the above example, that will try to run "make" w/o a
- # Makefile, which prints a useful error.
- # XXX MDX I'm all for it but this will differ from current dh_auto_build
- # behaviour (which is that dh_auto_build doesn't fail if
- # dh_auto_configure was not run). It is your call whether you are
- # willing to break this aspect of backwards compatibility.
if ($action eq "configure") {
return -x "configure";
}
my ($action) = @_;
# Handles build, test, install, clean; configure - next class
- # XXX JEH shouldn't it also handle configure, just as a no-op?
- # XXX MDX No, then cmake.mk would have no chance of hitting for
- # no good reason.
if (grep /^\Q$action\E$/, qw{build test install clean}) {
# This is always called in the source directory, but generally
# Makefiles are created (or live) in the the build directory.
# Handles everything
my $ret = -e "Build.PL";
- # XXX JEH what happens here if they run dh_auto_build,
- # forgetting dh_auto_configure? I think it will just
- # think it's not auto buildable and, assuming no other buildsystems
- # succeed, silently do nothing. Perhaps it would be better, then,
- # to omit the test below. Then, it would try to run ./Build
- # which doesn't exist, which should result in a semi-useful error.
- # XXX MDX Agreed. But it would not be fully backwards compatible
- # (see comment in autotools.mk why). Your call.
if ($action ne "configure") {
$ret &&= -e "Build";
}
my ($action)=@_;
# Handles configure, install; the rest - next class
- if ($action eq "install") {
- return -e "Makefile.PL";
- }
- # XXX JEH why test for configure here? If building or cleaning, and
- # a Makefile.PL exists, we know this class can handle those
- # actions -- it does so by inheriting from the makefile class.
- # XXX MDX Yes. But that's again different behaviour from current
- # (see comment in autotools.mk). Your call.
- elsif ($action eq "configure") {
+ if ($action eq "install" || $action eq "configure") {
return -e "Makefile.PL";
}
else {
# Copyright: © 2008-2009 Modestas Vainius
# License: GPL-2+
-# XXX JEH also it seems the functions in Dh_Buildsystems could be merged
-# into this same file.
-# XXX MDX I disagree. I think that mixing OO class and non-OO functions in the
-# same file is a bad style. What is more, these two modules have different
-# purposes (Dh_Buildsystems is an agregator of Dh_Buildsystem and its
-# derivatives). Moreover, we don't want Dh_Buildsystem to inherit from Exporter
-# (like Dh_Buildsystems do), do we?
package Debian::Debhelper::Dh_Buildsystem;
use strict;
# XXX MDX Yes, that warning stuff was a mess. I implemented your
# idea partitially.
#
-# XXX JEH (In turn that could be used to remove the pre_action, since that's the
-# only use of it -- the post_action is currently unused too. It could be
-# argued that these should be kept in case later buildsystems need them
-# though.)
-# XXX MDX Well, I think we could keep them (now both empty) for the reason
-# you mention.
-#
# XXX JEH AFAICS, there is only one reason you need an instance of the object
# if it can't build -- to list build systems. But that only needs
# DESCRIPTION and NAME, which could be considered to be class methods,
# In case of outside-source tree building, whole build directory
# gets wiped (if it exists) and 1 is returned. Otherwise, nothing
# is done and 0 is returned.
-# XXX JEH only makefile.pm uses this, move it there?
-# XXX MDX Well true, but I think this one is good to have for API
-# completeness near to mkdir_builddir and doit_in_builddir above.
-# I don't have strong feelings about it, but it looks more common
-# function than makefile specific to me.
sub clean_builddir {
my $self=shift;
if ($self->get_builddir()) {
use base 'Exporter';
our @EXPORT=qw(&buildsystems_init &buildsystems_do &load_buildsystem);
-# XXX JEH as noted, this has to match historical order for back-compat
-# XXX MDX Current dh_auto_* look like:
-# configure: autotools, perl_makemaker, perl_build
-# build: makefile, python_distutils, perl_build
-# test: makefile, perl_build
-# install: makefile (with perl_makermaker) hack, python_distutils, perl_build
-# clean: makefile, python_distutils, perl_build
-# So historical @BUILDSYSTEMS order (as per autodetection, see
-# check_auto_buildable() of the respective classes):
-# autotools (+configure; the rest - next class)
-# perl_makemaker (+configure +install (special hack); the rest - next class)
-# makefile (+build +test +install +clean; configure - next class)
-# python_distutils (handles everything)
-# perl_build (handles everything)
-# XXX JEH I think that makes sense..
-
# Historical order must be kept for backwards compatibility. New
# buildsystems MUST be added to the END of the list.
our @BUILDSYSTEMS = (
projects / debhelper.git / commitdiff