Re: Is it really possible to compile wxPerl ?

I don't think it is the case that we (or at least I) don't appreciate the huge effort it takes to develop and maintain wxPerl. 

I certainly haven't had any problems compiling wxWidgets itself.  It and the sample code with it seems to compile and work without problem.  The challenge is with getting Alien/wxPerl to work.  At least that is were I struggle with it.  

What is dotReader?  dotreader.com is a e-book reader site.  Is there a distribution for wxPerl available there somewhere?

Thanks,

Dan Freed

On Jan 19, 2007, at 2:53 PM, Eric Wilhelm wrote:

# from Beule, Franck

# on Friday 19 January 2007 06:01 am:

And for my conclusion, if it's hard to compile on Windows (someone

succeded on this task,

but he didn't explained how) and impossible to compile on Linux and

MacOSX,

does someone really use wxPerl ???

Yes, it is quite possible.  No, it is not easy.  IME, Alien::WxWidgets 

can be a bit of a pain.  I've not managed to successfully compile on 

windows, but getting the right tools installed on windows is a huge 

pain.  I built wxGTK on linux without any trouble, but Alien::WxWidgets 

is still a speed-bump there.  The mac works too, though getting it 

built as a universal binary is a huge pain because apple decided to put 

too much of the smarts into xcode and CPAN isn't having any of that.

Which is why dotReader has to provide out-of-the-box bundles for all 

three platforms.  That's not easy.  Dependency scanning is the current 

speedbump.

Consider the challenges:

  o compiling wxWidgets without user intervention (Alien)

  o compatibility with multiple wxWidgets versions

  o compatibility with multiple perl versions

  o various flaky windows environments (make, nmake, gcc, cc.exe, etc)

  o compatibility with multiple mac versions

    (mac testing is expensive: 1 OS per machine, no virtualizing,

     and apple end-of-lifes the old xcode on day one of the next OS)

And that's just the overhead to developing the perl binding.  

Unfortunately, until more people pitch in to strawberry perl, automated 

cross-platform testing, etc, this isn't going to get easier for 

end-users either.  wxPerl itself is very well done, but these huge 

barriers to entry make it hard to test, let alone contribute.

IMNSHO, the spam on this list doesn't help much.  The wiki is also a bit 

slow from this part of the world.  I think wxPerl's users, code, and 

documentation would really benefit from moving to the perl.org 

infrastructure (mail, svn, probably even hosting.)

--Eric

-- 

"Matter will be damaged in direct proportion to its value."

--Murphy's Constant

---------------------------------------------------

    http://scratchcomputing.com

---------------------------------------------------

-------------------------------------------------------------------------

Take Surveys. Earn Cash. Influence the Future of IT

Join SourceForge.net's Techsay panel and you'll get the chance to share your

opinions on IT & business topics through brief surveys - and earn cash

http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________

wxperl-users mailing list

wxperl-users@xxxxxxxxxxxxxxxxxxxxx

https://lists.sourceforge.net/lists/listinfo/wxperl-users

Daniell Freed

wintermte@xxxxxxxxx

Bereshit bara Elohim et hashamayim ve'et ha'arets...

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
wxperl-users mailing list
wxperl-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/wxperl-users