Bug#499225: Wish for waf support in dh_auto_build, dh_auto_clean, dh_auto_configure, dh_auto_install and dh_auto_test
Ryan Niebur wrote (in 2009): I've seen Luca's comment about waf being packaged, however the packaged version completely doesn't work for my package, so my build class continues to use ./waf. perhaps the build class shouldn't be added until the problem with the package is resolved and /usr/bin/waf can be used? I belive this is why the build system class did not get added to debhelper. It seems that waf has in the mean time still not been packaged. I'm not sure if it makes sense to add this class now, or not. -- see shy jo signature.asc Description: Digital signature
Bug#499225: Wish for waf support in dh_auto_build, dh_auto_clean, dh_auto_configure, dh_auto_install and dh_auto_test
Hi!
On Wed, Jul 01, 2009 at 07:55:41PM -0400, Joey Hess wrote:
Could you include a minimal copyright/license notice?
added.
sub check_auto_buildable {
my ($this, $step) = @_;
Could you please use tabs for indentation?
ran perltidy.
return(-e $this-get_sourcepath(waf));
In the original bug, Trent suggested also checking for
wscript, is there any reason not to do so? Maybe ./waf should be tested
to be executable too?
ok, fixed.
waf would also need to be added to the @BUILDSYSTEMS list in
Dh_Buildsystems.pm. Safest is to add it to the end, although that would
mean you'd need --buildsystem=waf if a source package also had a stub
autoconf or Makefile.
yes, I know. my patch doesn't include this because I'm not developing
this inside the git repo. Would you mind adding this for me when you
add my build class? :)
sub configure {
my $this=shift;
$this-_do_waf(configure, --prefix=/usr/, @_);
}
Should that perhaps be /usr? (As in autoconf.)
yes, I originally had it like that, but changed it to try (and fail)
to work around a (unrelated to my build class) bug. anyway, I put
it back now.
sub test {
my $this=shift;
$this-_do_waf(check, @_);
}
Is this going to quietly succeed if there is no test suite?
It needs to..
it should, as long as there's a test directory with wscript in
it. I added a check for this.
sub clean {
my $this=shift;
$this-_do_waf(distclean, @_);
$this-doit_in_sourcedir(rm, -rf, _build_);
_build_ is something distclean doesn't remove?
yes it does. I wonder why I thought it needed to be removed
manually...anyways, fixed.
I've seen Luca's comment about waf being packaged, however the
packaged version completely doesn't work for my package, so my build
class continues to use ./waf. perhaps the build class shouldn't be
added until the problem with the package is resolved and /usr/bin/waf
can be used?
Cheers,
Ryan
--
_
Ryan Niebur
ryanrya...@gmail.com
package Debian::Debhelper::Buildsystem::waf;
# Copyright: © 2009 Ryan Niebur
# License: GPL-2+
use strict;
use base 'Debian::Debhelper::Buildsystem';
sub DESCRIPTION {
waf;
}
sub check_auto_buildable {
my ( $this, $step ) = @_;
return ( -x $this-get_sourcepath(waf)
-e $this-get_sourcepath(wscript) );
}
sub new {
my $class = shift;
my $this = $class-SUPER::new(@_);
$this-enforce_in_source_building();
return $this;
}
sub _do_waf {
my $this = shift;
return $this-doit_in_sourcedir( ./waf, --nocache, @_ );
}
sub configure {
my $this = shift;
$this-_do_waf( configure, --prefix=/usr, @_ );
}
sub test {
my $this = shift;
if ( -e tests/wscript_build ) {
$this-_do_waf( check, @_ );
}
}
sub install {
my $this= shift;
my $destdir = shift;
$this-_do_waf( install, --destdir, $destdir, @_ );
}
sub build {
my $this = shift;
$this-_do_waf( build, @_ );
}
sub clean {
my $this = shift;
$this-_do_waf( distclean, @_ );
}
1;
signature.asc
Description: Digital signature
Bug#499225: Wish for waf support in dh_auto_build, dh_auto_clean, dh_auto_configure, dh_auto_install and dh_auto_test
tag 499225 patch
quit
here's a buildsystem class to add support for this. I would be
grateful if you would add it to the package.
also, while working on this I noticed in doc/PROGRAMMING it says:
A buildsystem class needs to inherit or define these methods: DESCRIPTION,
check_auto_buildable, build, test, install, clean.
I think configure should be added to that list, yes?
Thanks,
Ryan
--
_
Ryan Niebur
ryanrya...@gmail.com
package Debian::Debhelper::Buildsystem::waf;
use strict;
use base 'Debian::Debhelper::Buildsystem';
sub DESCRIPTION {
waf
}
sub check_auto_buildable {
my ($this, $step) = @_;
return(-e $this-get_sourcepath(waf));
}
sub new {
my $class=shift;
my $this= $class-SUPER::new(@_);
$this-enforce_in_source_building();
return $this;
}
sub _do_waf {
my $this = shift;
return $this-doit_in_sourcedir(./waf, --nocache, @_);
}
sub configure {
my $this=shift;
$this-_do_waf(configure, --prefix=/usr/, @_);
}
sub test {
my $this=shift;
$this-_do_waf(check, @_);
}
sub install {
my $this=shift;
my $destdir=shift;
$this-_do_waf(install, --destdir, $destdir, @_);
}
sub build {
my $this=shift;
$this-_do_waf(build, @_);
}
sub clean {
my $this=shift;
$this-_do_waf(distclean, @_);
$this-doit_in_sourcedir(rm, -rf, _build_);
}
1;
signature.asc
Description: Digital signature
Bug#499225: Wish for waf support in dh_auto_build, dh_auto_clean, dh_auto_configure, dh_auto_install and dh_auto_test
Ryan Niebur wrote:
here's a buildsystem class to add support for this. I would be
grateful if you would add it to the package.
Comments interspersed.
also, while working on this I noticed in doc/PROGRAMMING it says:
A buildsystem class needs to inherit or define these methods: DESCRIPTION,
check_auto_buildable, build, test, install, clean.
I think configure should be added to that list, yes?
Yes, done.
package Debian::Debhelper::Buildsystem::waf;
Could you include a minimal copyright/license notice?
sub check_auto_buildable {
my ($this, $step) = @_;
Could you please use tabs for indentation?
return(-e $this-get_sourcepath(waf));
In the original bug, Trent suggested also checking for
wscript, is there any reason not to do so? Maybe ./waf should be tested
to be executable too?
waf would also need to be added to the @BUILDSYSTEMS list in
Dh_Buildsystems.pm. Safest is to add it to the end, although that would
mean you'd need --buildsystem=waf if a source package also had a stub
autoconf or Makefile.
sub configure {
my $this=shift;
$this-_do_waf(configure, --prefix=/usr/, @_);
}
Should that perhaps be /usr? (As in autoconf.)
sub test {
my $this=shift;
$this-_do_waf(check, @_);
}
Is this going to quietly succeed if there is no test suite?
It needs to..
sub clean {
my $this=shift;
$this-_do_waf(distclean, @_);
$this-doit_in_sourcedir(rm, -rf, _build_);
_build_ is something distclean doesn't remove?
--
see shy jo
signature.asc
Description: Digital signature
Bug#499225: Wish for waf support in dh_auto_build, dh_auto_clean, dh_auto_configure, dh_auto_install and dh_auto_test
On Wed, Sep 17, 2008 at 01:24:39PM +1000, Trent W. Buck wrote: Package: debhelper Version: 7.0.15 Severity: wishlist waf is a configure/build infrastructure inspired by scons. It is currently used by the midori and xmms2 upstreams (and possibly others). It would be nice if the dh_auto_* scripts detected and used the waf. Note that Midori provides both waf and a deprecated autotools build infrastructure, so I'd prefer dh to prioritize waf higher than autotools when choosing which one to run. I guess the test for is this upstream using waf? should be -f waf and -f wscript According to ./waf --help, it has the following targets: configure build install clean dist distclean uninstall distcheck The first few map straight onto dh_auto_* rules; I don't know if distcheck = dh_auto_test. Possibly dh_auto_test should do nothing if it finds a ./waf file. Here's something that nearly works (for some reason, debian/tmp/usr/bin/midori disappears or isn't created). #!/usr/bin/make -f %: dh $@ clean: dh $@ ./waf --nocache distclean build: dh $@ --before configure ./waf --nocache configure --prefix=/usr dh $@ --after configure --until build ./waf --nocache build dh $@ --remaining binary: dh $@ --until dh_auto_install ./waf --nocache install --destdir=debian/tmp dh $@ --remaining --before dh_strip dh_strip --dbg-package=midori-dbg dh $@ --remaining -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#499225: Wish for waf support in dh_auto_build, dh_auto_clean, dh_auto_configure, dh_auto_install and dh_auto_test
Package: debhelper Version: 7.0.15 Severity: wishlist waf is a configure/build infrastructure inspired by scons. It is currently used by the midori and xmms2 upstreams (and possibly others). It would be nice if the dh_auto_* scripts detected and used the waf. Note that Midori provides both waf and a deprecated autotools build infrastructure, so I'd prefer dh to prioritize waf higher than autotools when choosing which one to run. I guess the test for is this upstream using waf? should be -f waf and -f wscript According to ./waf --help, it has the following targets: configure build install clean dist distclean uninstall distcheck The first few map straight onto dh_auto_* rules; I don't know if distcheck = dh_auto_test. Possibly dh_auto_test should do nothing if it finds a ./waf file. PS: note that unlike e.g. scons or python-setuptools, convention is for upstreams to include enough of waf to bootstrap itself from just a python dependency. Therefore I don't think it should matter that Debian has no waf package yet. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages debhelper depends on: ii binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina ii dpkg-dev1.14.22 Debian package development tools ii file4.25-1 Determines file type using magic ii html2text 1.3.2a-5 advanced HTML to text converter ii man-db 2.5.2-2 on-line manual pager ii perl5.10.0-13Larry Wall's Practical Extraction ii po-debconf 1.0.15 manage translated Debconf template debhelper recommends no packages. Versions of packages debhelper suggests: pn dh-make none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
