Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Making parrot portable

4 views
Skip to first unread message

Florian Ragwitz

unread,
Nov 14, 2005, 11:19:49 AM11/14/05
to perl6-i...@perl.org
Hello,

I'm the maintainer of the parrot Debian packages which are in Debian
unstable now. All Debian packages usually get built by the Debian build
daemon network so binaries for all architectures are available to the
users. This was also done with parrot. The [0] results scared me a bit.
Parrot only built fine on 3 architectures beside the i386-linux I am
running and failed for the rest.

0. http://buildd.debian.org/build.php?pkg=parrot

Therefor I want to make parrot a bit more portable. For some
architectures (mips, mipsel, arm, ..) the build failures are most
probably caused because jit is broken on those architectures. I haven't
looked very much into it yet. So volunteers are welcome.

Currently I'm trying to make it work on ia64. The reason for the failing
build on that arch is that the asm bits necessary for ia64 aren't copied
in the right place and compiled, so we get unresolved symbols on
linking everything together.

So I took a look at the code that should handle those things. Beside
it's ragged between several scripts in config/ it's also very
unportable. As the platform only perl's $^O ($OSNAME) is used. So it's
hard to differenciate between subarchitectures of an operating system
such as ia64-linux and ppc-linux. I want to do the necessary changes,
but I need some help. For example the exact value of $^O and
$Config{archname} for several architectures would be helpful.

I currently have access to arm, s390, ppc, alpha, mips, mipsel, sparc,
m68k, hppa and ia64 linux machines. It would be good if others could
provide some infos about other architectures, especially non-linux ones.

After I've collected enough informations I'll start implementing the
necessary changes. I hope it'll be done by the end of this week. I'm not
sure how I should handle that though. I guess it might break parrot
building for a while. So shall I do it in trunk, do a local svk branch
and provide snapshots or bloat the repository some more and create a new
svn branch?


Regards,
Flo

--
BOFH excuse #144:
Too few computrons available.

signature.asc

Chip Salzenberg

unread,
Nov 14, 2005, 11:30:07 PM11/14/05
to Florian Ragwitz, perl6-i...@perl.org
On Mon, Nov 14, 2005 at 05:19:49PM +0100, Florian Ragwitz wrote:
> After I've collected enough informations I'll start implementing the
> necessary changes. I hope it'll be done by the end of this week. I'm not
> sure how I should handle that though. I guess it might break parrot
> building for a while. So shall I do it in trunk, do a local svk branch
> and provide snapshots or bloat the repository some more and create a new
> svn branch?

If you're doing all your own development and testing, I'd suggest a
local svk branch. Providing snapshots is welcome but not mandatory.
Once you've experimented enough to know for sure that your changes are
an overall improvement (and specifically that they don't break the
architectures that work now), you could commit your work to the trunk.

Thanks muchly for asking...
--
Chip Salzenberg <ch...@debian.org>

0 new messages