develooper Front page | perl.perl5.porters | Postings from November 2014

Re: Test farm

Thread Previous | Thread Next
From:
H.Merijn Brand
Date:
November 3, 2014 07:53
Subject:
Re: Test farm
Message ID:
20141103085320.6be0505b@pc09.procura.nl
On Mon, 27 Oct 2014 16:23:27 -0200, "Vincent Pit (VPIT)"
<perl@profvince.com> wrote:

> > That implies that every new build will be 64bit
> >
> > What would be most useful ...
> >
> > 1. Rebuild all builds for 64bit (will take a while)

Started this.

I am unable to build older than 5.6.0
No idea yet if that is Devel::PatchPerl's fault or due to system
configuration. Building 96 perls + minimum additions for testing takes
a bit

I have now rebuilt all unthreaded 64bitall versions and am in the
process of adding minimal extensions from CPAN (DBI, Data::Peek,
Test::Warnings ...)

When all of that is done, I'll redo for threaded 64all longdouble

When all of that is done, I'll sync to dromedary

> > 2. Find a way to build 32bit versions on a native 64bit machine. This I
> >     never tried, as my laptop was 32bit and the default was to build
> >     32bit.
> >
> > Doing 2. will also mean I have to chase whatever 32bit libs were used
> > and replaced with 64bit versions in the upgrade process without
> > installing the -32bit counterpart.
> >
> > Doing neither will render the farm less useless as - at least IMHO -
> > 64bit builds cannot be compared to 32bit builds on the same arch
> >
> > Opinions welcome
> 
> In the past, I tried to use your farm on dromedary to build some XS 
> modules, but if my memories don't fool me it failed exactly because of 
> this 32bits/64bits mismatch. So I believe 1°) would be more useful in 
> the long run.

Just dropping all effort put in the 32bit versions seems like a waste
of effort. I want to see if it is possible to "move" them.

I tried moving /media/Tux/perls to /media/Tux/perls-32 and I am well
aware that that would not run out-of the box as planned. Some parts of
the "PATH" are hardwired. Some of those parts are easy to fix. Like
perl -pi on all .packlist files (which have no impact on runtime). That
leaves me with these files for 5.20.1:

/media/Tux/perls-32/lib $ grep -alr /media/Tux/perls {,site_perl/}5.20.1 | fgrep -v .packlist
5.20.1/i686-linux-64int/Config_heavy.pl
5.20.1/i686-linux-64int/CORE/libperl.a
5.20.1/i686-linux-64int/CORE/config.h
5.20.1/i686-linux-64int/perllocal.pod
5.20.1/i686-linux-64int/Config.pm
5.20.1/CPAN/Config.pm
site_perl/5.20.1/i686-linux-64int/auto/DBI/DBI.so

Again, a perl -pi on Config_heavy.pl, config.h, perllocal.pod and
both Config.pm will reduce that, but that will NOT fix hardwired
dependencies in perllib.a and DBI.so

Is this a blocker, and do I just rm -rf the 32bit tree or is there a
workaround to extend the perl test farm?

> Vincent


-- 
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.21   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/        http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About