Bug#288806: cdbs: support for perl modules that use Module::Build
Package: cdbs
Version: 0.4.49
Followup-For: Bug #288806
Just overriding DEB_MAKE_INVOKE doesn't work for me. It fails when the
makefile class tries to run $(DEB_MAKE_INVOKE) -k $(DEB_MAKE_CLEAN_TARGET)
Instead I've made the attached patch which provides native support for
Module::Build including code to detect which build system is used by
prefering Build.PL over Makefile.PL.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.18-4-xen-amd64 (SMP w/1 CPU core)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=ANSI_X3.4-1968)
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/bash
cdbs depends on no packages.
Versions of packages cdbs recommends:
ii autotools-dev 20070725.1 Update infrastructure for config.{
ii debhelper 5.0.57 helper programs for debian/rules
-- no debconf information
--- /usr/share/cdbs/1/class/perlmodule.mk 2007-05-20 18:13:10.0
+0200
+++ perlmodule.mk 2007-11-09 11:30:08.271007921 +0100
@@ -28,23 +28,58 @@
# Make sure that CDBS_BUILD_DEPENDS is initialised
include $(_cdbs_rules_path)/buildvars.mk$(_cdbs_makefile_suffix)
+DEB_PERL_BUILDSYSTEM := $(shell test -e Build.PL echo Module::Build)
+DEB_PERL_BUILDSYSTEM ?= MakeMaker
+
# Dependency according to Perl policy 4.3
# (contrary to common misunderstanding a tighter dependency on perl 5.8
# was only temporarily needed when 5.8 was introduced into Debian sid.)
CDBS_BUILD_DEPENDS := $(CDBS_BUILD_DEPENDS), perl (= 5.6.0-16)
+ifneq ($(DEB_BUILDDIR),$(DEB_SRCDIR))
+$(error DEB_BUILDDIR and DEB_SRCDIR must be the same for Perl builds)
+endif
+
+ifeq ($(DEB_PERL_BUILDSYSTEM),Module::Build)
+
+include $(_cdbs_rules_path)/buildcore.mk$(_cdbs_makefile_suffix)
+
+common-configure-arch common-configure-indep:: Build
+Build:
+ (cd $(DEB_BUILDDIR) perl Build.PL --installdirs vendor
$(DEB_MODULEBUILD_USER_FLAGS) )
+
+common-build-arch common-build-indep:: debian/stamp-makefile-build
+debian/stamp-perl-build:
+ ./Build build
+ touch $@
+
+common-install-arch common-install-indep:: common-install-impl
+common-install-impl::
+ ./Build install destdir=$(DEB_DESTDIR)
+
+ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
+common-build-arch common-build-indep:: debian/stamp-perl-check
+debian/stamp-perl-check: debian/stamp-perl-build
+ ./Build test
+ touch $@
+endif
+
+clean::
+ -./Build realclean
+ -rm -f debian/stamp-perl-*
+
+else
+
include $(_cdbs_class_path)/perlmodule-vars.mk$(_cdbs_makefile_suffix)
include $(_cdbs_class_path)/makefile.mk$(_cdbs_makefile_suffix)
DEB_MAKEMAKER_PACKAGE ?= tmp
-ifneq ($(DEB_BUILDDIR),$(DEB_SRCDIR))
-$(error DEB_BUILDDIR and DEB_SRCDIR must be the same for Perl builds)
-endif
-
common-configure-arch common-configure-indep:: Makefile
Makefile:
(cd $(DEB_BUILDDIR) $(DEB_MAKEMAKER_INVOKE)
$(DEB_MAKEMAKER_USER_FLAGS) )
endif
+
+endif
Bug#288806: [Build-common-hackers] Bug#288806: cdbs: support for perl modules that use Module::Build
Looks sane to me, generally. But... +ifneq ($(DEB_BUILDDIR),$(DEB_SRCDIR)) +$(error DEB_BUILDDIR and DEB_SRCDIR must be the same for Perl builds) +endif If I understand Fr=C3=A9d=C3=A9ric correctly, the above restriction is no= t necessary when using Build directly. I haven't tested, so this is just speculation for now... Another thing is worrying about existing packages - do we not risk breaking some current use of CDBS by changing this now? If so, it might be better to check for Build.PL but instead of setting DEB_PERL_BUILDSYSTEM only warn about it. - Jonas --=20 * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er n=C3=A6r: http://www.shibumi.org/eoti.htm signature.asc Description: OpenPGP digital signature
Bug#288806: [Build-common-hackers] Bug#288806: cdbs: support for perl modules that use Module::Build
Jonas Smedegaard [EMAIL PROTECTED] writes: Looks sane to me, generally. But... +ifneq ($(DEB_BUILDDIR),$(DEB_SRCDIR)) +$(error DEB_BUILDDIR and DEB_SRCDIR must be the same for Perl builds) +endif If I understand Fr=C3=A9d=C3=A9ric correctly, the above restriction is not necessary when using Build directly. I haven't tested, so this is just speculation for now... Wasn't sure about this either. So I just left it in for both systems. Another thing is worrying about existing packages - do we not risk breaking some current use of CDBS by changing this now? If so, it might be better to check for Build.PL but instead of setting DEB_PERL_BUILDSYSTEM only warn about it. I would really hate having a long term solution prefering a compatability layer over using Module::Build directly. It is a problem that you can't easily override the test som it might be preferable to make the setting DEB_PERL_BUILDSYSTEM ?= $(shell test -e Build.PL echo Module::Build) DEB_PERL_BUILDSYSTEM ?= MakeMaker Yes, exisitng packages may fail but it is easily fixed by setting DEB_PERL_BUILDSYSTEM to MakeMaker (or anything but Module::Build). //Makholm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#288806: [Build-common-hackers] Bug#288806: Bug#288806: cdbs: support for perl modules that use Module::Build
Peter Makholm skrev: Jonas Smedegaard [EMAIL PROTECTED] writes: =20 Looks sane to me, generally. But... +ifneq ($(DEB_BUILDDIR),$(DEB_SRCDIR)) +$(error DEB_BUILDDIR and DEB_SRCDIR must be the same for Perl builds= ) +endif If I understand Fr=3DC3=3DA9d=3DC3=3DA9ric correctly, the above restri= ction is not necessary when using Build directly. I haven't tested, so this is just= speculation for now... =20 Wasn't sure about this either. So I just left it in for both systems. Ah, ok. Makes sense :-) Another thing is worrying about existing packages - do we not risk breaking some current use of CDBS by changing this now? If so, it might be better to check for Build.PL but instead of setting= DEB_PERL_BUILDSYSTEM only warn about it. =20 I would really hate having a long term solution prefering a compatability layer over using Module::Build directly. Agreed, but we must remain backwards compatible: # TODO: Favor Module::Build over MakeMaker DEB_PERL_BUILDSYSTEM ?=3D MakeMaker $(and $(filter MakeMaker,$(DEB_PERL_BUILDSYSTEM)),$(wildcard Build.PL),$(warning use of MakeMaker is deprecated, please set DEB_PERL_BUILDSYSTEM=3DModule::Build) (the last 3 lines above as a single line). When (or if) it is some day decided to bump the cdbs ABI, we can favor Module::Build and only use MakeMaker as fallback. Is that acceptable? (do my reasoning make sense at all?) - Jonas --=20 * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er n=E6r: http://www.shibumi.org/eoti.htm signature.asc Description: OpenPGP digital signature
Bug#288806: cdbs: support for perl modules that use Module::Build
On Wed, Oct 05, 2005 at 01:22:49PM -0400, Charles Fry wrote: At least in my case, the only change necessary to make Module::Build work was: DEB_MAKEMAKER_INVOKE = /usr/bin/perl Makefile.PL installdirs=vendor \ destdir=$(DEB_DESTDIR) noprompts=1 DEB_MAKE_INSTALL_TARGET = install My own approach was slightly different: DEB_MAKE_INVOKE := ./Build DEB_MAKE_BUILD_TARGET := build DEB_MAKE_INSTALL_TARGET := install --destdir $(if $(DEB_MAKEMAKER_PACKAGE),$(CURDIR)/debian/$(DEB_MAKEMAKER_PACKAGE),$(DEB_DESTDIR)) (Whether one has any advantage over the other is left as an exercise to the reader.) The Module::Build documentation said that destdir could be specified as an install parameter, but I couldn't get that to work. It's Module::Build::Compat, which is responsible for the Makefile legacy support, that's crippled in that way. ./Build supports install-time options correctly. -- Packages should build-depend on what they should build-depend. -- Santiago Vila on debian-devel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
