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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxperl-users

Daniell Freed
wintermte@gmail.com
Bereshit bara Elohim et hashamayim ve'et ha'arets...