Re: [wxperl-users] Is it really possible to compile wxPerl ?

[Daniell F. <win...@gm...>]

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

Daniell Freed
win...@gm...
Bereshit bara Elohim et hashamayim ve'et ha'arets...