Bug#538978: please add support for multiple python version to more build classes
[Joey Hess, 2011-02-24] If this were say, rewritten in python :) and factored out into a standalone program with a name like python-multibuild, and included in some python development package, then debhelper and rules files could just call it, and pass it the setup.py to run and the action to do. I'm interested in writing such tool and shipping it in python package, could you elaborate a little bit more about API? What arguments do you want to pass? Only something like this: $ python-multibuild build $ python-multibuild install $ python-multibuild test $ python-multibuild clean or will you also pass more options, like build dir (the one with setup.py file) for example? -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538978: please add support for multiple python version to more build classes
Piotr Ozarowski wrote: [Joey Hess, 2011-02-24] If this were say, rewritten in python :) and factored out into a standalone program with a name like python-multibuild, and included in some python development package, then debhelper and rules files could just call it, and pass it the setup.py to run and the action to do. I'm interested in writing such tool and shipping it in python package, could you elaborate a little bit more about API? What arguments do you want to pass? Only something like this: Anything that makes sense if the tool is used manually in a rules file should be usable by debhelper, I guess. -- see shy jo signature.asc Description: Digital signature
Bug#538978: please add support for multiple python version to more build classes
Hi Dne Wed, 5 Aug 2009 09:55:50 -0400 Joey Hess jo...@debian.org napsal(a): Michal Čihař wrote: I know it would be hard to find some solution which would help in most cases. But I hate to put the logic to compile for all python versions to all debian/rules. It would be great if this logic can be somehow separated and reused independently of build system. That logic follows below. If this were say, rewritten in python :) and factored out into a standalone program with a name like python-multibuild, and included in some python development package, then debhelper and rules files could just call it, and pass it the setup.py to run and the action to do. Hmm, that sounds like a way to go if we really want to build binaries for more Python versions. I will try to look more deeply into this topic, putting it to my todo list to investigate later. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Bug#538978: please add support for multiple python version to more build classes
Hi Dne Fri, 31 Jul 2009 11:23:42 -0400 Joey Hess jo...@debian.org napsal(a): This seems far too much an edge case and complicated (and unlikely to be usable for everything anyway) to do. I know it would be hard to find some solution which would help in most cases. But I hate to put the logic to compile for all python versions to all debian/rules. It would be great if this logic can be somehow separated and reused independently of build system. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Bug#538978: please add support for multiple python version to more build classes
Michal Čihař wrote:
I know it would be hard to find some solution which would help in most
cases. But I hate to put the logic to compile for all python versions
to all debian/rules. It would be great if this logic can be somehow
separated and reused independently of build system.
That logic follows below.
If this were say, rewritten in python :) and factored out into a standalone
program with a name like python-multibuild, and included in some python
development package, then debhelper and rules files could just call it,
and pass it the setup.py to run and the action to do.
I'd love to remove this code from debhelper, if we can find someplace
else to put it.
sub dbg_build_needed {
my $this=shift;
my $act=shift;
# Return a list of python-dbg package which are listed
# in the build-dependencies. This is kinda ugly, but building
# dbg extensions without checking if they're supposed to be
# built may result in various FTBFS if the package is not
# built in a clean chroot.
my @dbg;
open (CONTROL, 'debian/control') ||
error(cannot read debian/control: $!\n);
foreach my $builddeps (join('', CONTROL) =~
/^Build-Depends[^:]*:.*\n(?:^[^\w\n].*\n)*/gmi) {
while ($builddeps =~ /(python[^, ]*-dbg)/g) {
push @dbg, $1;
}
}
close CONTROL;
return @dbg;
}
sub setup_py {
my $this=shift;
my $act=shift;
# We need to to run setup.py with the default python first
# as distutils/setuptools modifies the shebang lines of scripts.
# This ensures that #!/usr/bin/python is used and not pythonX.Y
# Take into account that the default Python must not be in
# the requested Python versions.
# Then, run setup.py with each available python, to build
# extensions for each.
my $python_default = `pyversions -d`;
$python_default =~ s/^\s+//;
$python_default =~ s/\s+$//;
my @python_requested = split ' ', `pyversions -r 2/dev/null`;
if (grep /^\Q$python_default\E/, @python_requested) {
@python_requested = (python, grep(!/^\Q$python_default\E/,
@python_requested));
}
my @python_dbg;
my @dbg_build_needed = $this-dbg_build_needed();
foreach my $python (map { $_.-dbg } @python_requested) {
if (grep /^(python-all-dbg|\Q$python\E)/, @dbg_build_needed) {
push @python_dbg, $python;
}
elsif (($python eq python-dbg)
and (grep /^\Q$python_default\E/, @dbg_build_needed)) {
push @python_dbg, $python_default.-dbg;
}
}
foreach my $python (@python_requested, @python_dbg) {
if (-x /usr/bin/.$python) {
# effectively this runs system($python, setup.py,
$act, @_);
$this-doit_in_sourcedir($python, setup.py, $act, @_);
}
}
}
--
see shy jo
signature.asc
Description: Digital signature
Bug#538978: please add support for multiple python version to more build classes
Michal Čihař wrote: currently only distutils build class does support building for multiple python versions. However python modules are also shipped in various other package which use different build systems (rpm with autoconf, Gammu with CMake or pyexiv2 with SCons, when looking at mine packages). It would be great if this functionality could be generic, so that I do not need to duplicate all the code to build using all python version in every package. I know this can be quite tricky, because each package might take different parameters to achieve this, so this is something what needs to be configurable by parameter, something like: dh_auto_configure --build-system=cmake --multi-python=-DBUILD_PYTHON= What would expand to invoking cmake several times passing it - -DBUILD_PYTHON=/usr/bin/pythonX.Y for all Python versions it should use. This seems far too much an edge case and complicated (and unlikely to be usable for everything anyway) to do. -- see shy jo signature.asc Description: Digital signature
Bug#538978: please add support for multiple python version to more build classes
Package: debhelper Version: 7.3.8 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi currently only distutils build class does support building for multiple python versions. However python modules are also shipped in various other package which use different build systems (rpm with autoconf, Gammu with CMake or pyexiv2 with SCons, when looking at mine packages). It would be great if this functionality could be generic, so that I do not need to duplicate all the code to build using all python version in every package. I know this can be quite tricky, because each package might take different parameters to achieve this, so this is something what needs to be configurable by parameter, something like: dh_auto_configure --build-system=cmake --multi-python=-DBUILD_PYTHON= What would expand to invoking cmake several times passing it - -DBUILD_PYTHON=/usr/bin/pythonX.Y for all Python versions it should use. If you want to see examples look at above mentioned packages or just catch me at DebConf. - -- Michal Čihař | http://cihar.com | http://blog.cihar.com - -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/1 CPU core) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages debhelper depends on: ii binutils 2.19.51.20090723-1 The GNU assembler, linker and bina ii dpkg-dev 1.15.3.1 Debian package development tools ii file 5.03-1 Determines file type using magic ii html2text 1.3.2a-14 advanced HTML to text converter ii man-db2.5.5-3on-line manual pager ii perl 5.10.0-24 Larry Wall's Practical Extraction ii perl-base 5.10.0-24 minimal Perl system ii po-debconf1.0.16 tool for managing templates file t debhelper recommends no packages. Versions of packages debhelper suggests: pn dh-make none (no description available) - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpuzyAACgkQ3DVS6DbnVgQb8wCg0GtJaeVF9Xlo8R2crBKDbuXr WwMAnRTGhlU9Y6dUmaemB1d2sTU8NVkT =EsHj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
