On Mon, 27 May 2013 10:29:42 +0200 Mathieu Parent
<math.par...@gmail.com> wrote:
> Package: debhelper
> Version: 9.20130518
> Severity: whishlist
> X-Debbugs-CC: pkg-php-p...@lists.alioth.debian.org
>
> Hi Joey,
>
> For the pkg-php-tools [1] package, which enhance debhelper, I need to
> change the sourcedir when building PECL [2] package.
>
> [1]: http://anonscm.debian.org/gitweb/?p=pkg-php/pkg-php-tools.git;a=summary
> [2]: http://www.php.net/manual/en/install.pecl.phpize.php
>
> The wanted workflow on configure:
> - set sourcedir to Foo-0.0.0
> - phpize
> - pass to parent Debian::Debhelper::Buildsystem::autoconf configure()
> - set sourcedir back to top
>
> The wanted workflow on build:
> - set sourcedir to Foo-0.0.0
> - pass to parent Debian::Debhelper::Buildsystem::autoconf build()
> - set sourcedir back to top
>
> The wanted workflow on install:
> - set sourcedir to Foo-0.0.0
> - pass to parent Debian::Debhelper::Buildsystem::autoconf install()
> - set sourcedir back to top
>
> Wanted API:
> - push_sourcedir (with the same checks as in
> Debian::Debhelper::Buildsystem::new())
> - pop_sourcedir
>
> Or:
> - set_sourcedir (with the same checks as in
> Debian::Debhelper::Buildsystem::new())
>
> I'm open to any better solution.
>
> Regards
> --
> Mathieu Parent
>
>
Hi Mathieu,
Apologies for the long wait before picking this up.
Since you filed this bug, debhelper has gotten a new model for build
systems that may be relevant to this case. The described build flows
looks a look existing build generator flows (a la meson+ninja or
cmake+make[1]).
The phppear have some differences to this theme as such debhelper does
not currently support exactly the phppear use-case. I am hoping we can
come to a solution on that.
If phppear would be converted to generator buildsystem like meson, then
it would probably look something like this (mix-pseudo code, mix real code):
"""
# Remove 'use base "Debian::Debhelper::Buildsystem::autoconf";'
[...]
sub IS_GENERATOR_BUILD_SYSTEM {
return 1;
}
sub SUPPORTED_TARGET_BUILD_SYSTEMS {
return qw(autoconf);
}
sub _get_peardir {
[...]
}
# This sub does *not* exist yet
sub _initialize_target_buildsystem {
my ($this, $target_bs_options, @args) = shift;
$target_bs_options->{'sourcedir'} = $this->_get_peardir;
$target_bs_options->{'builddir'} = $this->_get_peardir;
return $this->SUPER::_initialize_target_buildsystem(
$target_bs_options, @args);
}
sub configure {
my $this=shift;
$this->get_targetbuildsystem->mkdir_builddir;
$this->get_targetbuildsystem->doit_in_builddir('phpize');
return $this->SUPER::configure(@_);
}
[...]
"""
The configure is from your concept description; I realise that the real
phppear build system is "slightly" more complex than that.
The most difficult issue is if you need to extract data to make
_get_peardir work, which may only be available if phppear is a valid
buildsystem for the concrete package. However, debhelper currently
initializes the target buildsystem immediately and we rely on this
elsewhere in debhelper (e.g. in dh_auto_configure --list).
Just to confirm I got some details correct:
* Is it correctly understood of me that phppear *conditionally* uses
autoconf as a generated build system (i.e. there are packages where
phppear does everything without ever using the autoconf bits)?
* Is it correctly understood that phppear potentially needs two
distinct "build directories"? One for itself and a generated one for
the autoconf parts?
* Is the exact name returned by _get_peardir important or just "nice to
have"?
Finally, a few drive-by remarks after reviewing the phppear build system
(in case they are useful to you):
* _get_mainpackage looks like an expensive version of $dh{MAINPACKAGE}
(with some theoretical corner cases where dh_listpackages might give
you a different result).
- Is anything preventing you from using $dh{MAINPACKAGE}?
* If you like to avoid shell, then the complex_doit call can be
replaced by using doit({stdout => $path}, ...). Requires buster
or later (I can dig out the exact version of debhelper if relevant,
but I did not see any backports for pkg-php-tools, so I assumed it
was not relevant).
Thanks,
~Niels
[1] Strictly speaking, autoconf should be autoconf+make. But historical
reasons prevent the split.
