Parrot under Subversion / ICU

Leopold Toetsch

unread,

Mar 31, 2005, 5:01:15 AM3/31/05

to Perl 6 Internals

We gonna switch to SVN soon.

citing Chip:

I think it would be a Good Thing for Parrot to live under Subversion
rather than CVS. Just the change sets and rename tracking is enough
reason, IMO.

and:

Announcement should
also mention that we're not going to move icu over, so people should
download libicu and/or submit patches to build without it.

1) patches are very welcome that

$ perl Configure.pl --without-icu

This was already discussed, there's probably a TODO item for it

2) please download the latest ICU and verify that it still works. Docu
updates how to build with ICU are as well very welcome.

3) If no one utters a killer argument against, we'll switch to SVN

4) Makefile cleanups to remove in-tree icu build stuff

leo

Ron Blaschke

unread,

Mar 31, 2005, 2:29:23 PM3/31/05

to Leopold Toetsch, Perl 6 Internals

Leopold Toetsch wrote:
> We gonna switch to SVN soon.

Lovely. :-)

> citing Chip:
> I think it would be a Good Thing for Parrot to live under Subversion
> rather than CVS. Just the change sets and rename tracking is enough
> reason, IMO.

I've been using SVN happily for almost a year now. It works nicely
even on Windows. I've never had much use for the rename support, but
I really like the atomic commits, with a single revision number for
the whole repository. It's way easier to track changes (either that
or I have never really understood CVS). Also, the really cheap
branches / tags are quite nice.

> Announcement should
> also mention that we're not going to move icu over, so people should
> download libicu and/or submit patches to build without it.

No problem on Windows, never managed to get the ICU distributed with
parrot running, anyway.

> 2) please download the latest ICU and verify that it still works. Docu
> updates how to build with ICU are as well very welcome.

The precompiled ICU 3.2 on VC++ 7.1 is good on Windows. They renamed
F<lib/icudata.lib> to <lib/icudt.lib> from 3.0 to 3.2, though.

Ron

Andy Dougherty

unread,

Apr 1, 2005, 2:35:37 PM4/1/05

to Perl 6 Internals

On Thu, 31 Mar 2005, Leopold Toetsch wrote:

> We gonna switch to SVN soon.

> 3) If no one utters a killer argument against, we'll switch to SVN

I tried svn again. I'm happy to report it worked much better than it did
the last time I tried it. For one thing, it actually compiled for me.

It's still slower than cvs, but not as bad as it was before. An initial
checkout took 56 minutes; subsequent updates took about 2 to 3 times as
long as CVS. I'd judge that as still quite useable. So, no killer
arguments here.

--
Andy Dougherty doug...@lafayette.edu

Leopold Toetsch

unread,

Apr 3, 2005, 4:06:56 AM4/3/05

to Jens Rieks, perl6-i...@perl.org

Jens Rieks wrote:

> On Thursday 31 March 2005 12:01, Leopold Toetsch wrote:
>
>>4) Makefile cleanups to remove in-tree icu build stuff
>

> Patch ready. When should I commit it?

This was the 4th step in the plan. First we need:

1) patches are very welcome that

$ perl Configure.pl --without-icu

then we verify that we can build with a system ICU or without. Then we
can move over to SVN and procede with step 4).
As the icu/ directory isn't moved to SVN ...

> Should I remove the icu/ directory, too?

... this is void then.

> jens

leo

Jens Rieks

unread,

Apr 3, 2005, 7:31:24 AM4/3/05

to perl6-i...@perl.org, Leopold Toetsch

On Sunday 03 April 2005 10:06, Leopold Toetsch wrote:
> Jens Rieks wrote:
> > On Thursday 31 March 2005 12:01, Leopold Toetsch wrote:
> >>4) Makefile cleanups to remove in-tree icu build stuff
> >
> > Patch ready. When should I commit it?
>
> This was the 4th step in the plan. First we need:
>
> 1) patches are very welcome that
>
> $ perl Configure.pl --without-icu

Okay. I wasn't sure if the specific order matters.
I'll try to implement --without-icu now...

> then we verify that we can build with a system ICU or without. Then we
> can move over to SVN and procede with step 4).

Why don't we remove the support for the bundled ICU prior to the move?
I think that it is easier this way to verify that the imported version works.
(manifest check fails w/o the icu/ directory etc.)

Ron Blaschke

unread,

Apr 3, 2005, 8:06:44 AM4/3/05

to Jens Rieks, perl6-i...@perl.org, Leopold Toetsch

Jens Rieks wrote:
> On Sunday 03 April 2005 10:06, Leopold Toetsch wrote:
>> Jens Rieks wrote:

[snip]

>> then we verify that we can build with a system ICU or without. Then we
>> can move over to SVN and procede with step 4).
> Why don't we remove the support for the bundled ICU prior to the move?
> I think that it is easier this way to verify that the imported version works.
> (manifest check fails w/o the icu/ directory etc.)

I'd reckon once C<--without-icu> is in place, one should be able to
run

$rm -rf icu
$perl Configure --without-icu --nomanicheck

So it shouldn't really matter when exactly F<icu/> is removed.

Just my thoughts,
Ron

Jens Rieks

unread,

Apr 3, 2005, 9:41:39 AM4/3/05

to perl6-i...@perl.org, Ron Blaschke, Leopold Toetsch

On Sunday 03 April 2005 14:06, Ron Blaschke wrote:
> I'd reckon once C<--without-icu> is in place, one should be able to
> run
>
> $rm -rf icu
> $perl Configure --without-icu --nomanicheck
>
> So it shouldn't really matter when exactly F<icu/> is removed.

Hmm, okay. Thats indeed true.

I've attached the patch that implements --without-icu.
Comments welcome.

> Just my thoughts,
> Ron
jens

remove-icu.patch

Leopold Toetsch

unread,

Apr 5, 2005, 4:34:25 AM4/5/05

to Jens Rieks, perl6-i...@perl.org

Jens Rieks <par...@jensbeimsurfen.de> wrote:

> I've attached the patch that implements --without-icu.
> Comments welcome.

1) --without-icu works fine

Needed a few changes to get rid of warnings in lib/Parrot/Test.pm when
running make src_tests

replaced isblank, it's a gcc extension

2) running Configure w/o ICU options and w/o installed system ICU did still
enable the blib/lib hack. Now it defaults to building without ICU

3) after installing ICU, icu-config detects the libs and Parrot builds
with icu 3.2 (at least after ldconfig -X is run first :)