On Tue, Jun 14, 2011 at 6:19 PM, Mark Dootson <mark.doot...@znix.com> wrote: > Hi, > > Took a look at Wx::Scintilla - great work. With a minor build tweak (on my > build systems some stuff isn't in the assumed locations - I'll post a patch) > builds and works on Windows for me with a number of Perls.
Thanks. I appreciate your help. Hopefully I will be able to test and integrate your patches ASAP. > > For info, Wx already has a build system for Wx extensions - but using EUMM. > > As an example, the attacked Makefile builds Wx::Scintilla if the scintilla > wxWidgets dll is already built. > > The only hard coded part is the LIBS line which I was too lazy to set up > properly. > > Obviously, it is of no use to your build system - but the point is, you > don't have to figure out the correct compiler and linker lines, the > Wx::build modules do that for you. > > I guess you could use and adapt Wx::build code for a Module::Build install. > > Building the scintilla wxWidgets dll is a bit more problematic. > True, the major part is the building of Scintilla and the Wx DLL. On windows, things are simple, Alien::wxWidgets is installed from source. On the non-win32 platforms, you usually have an existing wxWidgets libary to link against or built from source. > However, I'm pretty sure that the methods provided by Alien::wxWidgets give > you more or less everything you need to create the necessary compiler and > linker lines without having to work it all out yourself. > Yes i re-used a lot of them to avoid hard-coding stuff. That is why I asked about the 'require Alien::wxWidgets; print Alien::wxWidgets->compiler' instead of 'use Alien::wxWidgets'. 'use Alien::wxWidgets ()' does not work also. > I'll see if I can do the necessary in your Module::Build bits to get build > working across Windows/Linux/Mac using just the info from Wx::build and > Alien::wxWidgets. > Wx::build has been on my radar but i wanted to understand the whole process first (i.e. to control it). On some hair-pulling occasions, i wanted to go back to Module::Install for its ease of use when compiling XS and stuff on windows compared to the false Module::Build XS assumptions which i replaced with custom code. 'make' seems to be a more sensible solution when you have a lot of C and XS source files to compile (better modification dependency checking and faster development process). > I'll certainly upload and maintain PPMs for Wx::Scintilla and I'll try to > better keep up with PPMs for Padre releases. For Padre, I need to 'diary on' > say 7 days from a Padre CPAN release until the engines of ActiveState have > caught up with PPM builds for latest non-wx dependencies. > > Hopefully have some build patches soon. Great! Looking forward to see your patches. What about Citrus Perl? > > Regards > > Mark > > > > > On 13/06/2011 14:51, Ahmad Zawawi wrote: >> >> Oops forgot to CC the wxPerl users list :) >> >> >> ---------- Forwarded message ---------- >> From: Ahmad Zawawi<ahmad.zaw...@gmail.com> >> Date: Mon, Jun 13, 2011 at 4:40 PM >> Subject: Re: Alien::wxWidgets questions >> To: Mark Dootson<mark.doot...@znix.com> >> >> >> Hi, >> >> Thanks for the quick reply :) >> >>> >>> I use mingw-w64 32 and 64 bit gcc compilers to build against all current >>> versions of ActivePerl. A recent gcc from mingw.org works too. >>> >> >> I was referring the broken ActivePerl PPM gcc + dmake support. The one >> you get when you run cpan Alien::wxWidgets (after a fresh ActivePerl >> installation) and it tells you that it cannot find a working compiler >> and it downloads the one from ActiveState PPM repository. I will post >> the exact log if you are interested. VC++ CL is not registered in PATH >> unless you explicity call "%VS_STUDIO_HOME%\VC\bin\vcvars32.bat" >> first. >> >>> Occasionally, in the past, a particular release of ActivePerl broke gcc >>> compatibility, though I can't remember the last one. (one of the 5.10.1 >>> releases) >>> >>> For this reason I'm in the habit of still using ExtUtils::FakeConfig, >>> creating my own libperl5xx.a and loading a Config_w64.pm >>> ( http://www.wxperl.co.uk/building/Config_w64.pm ) >>> >>>> - What are the supported Alien::wxWidgets configurations of over >>>> Linux, Mac OS X and other platforms? >>> >>> Not sure what you mean? >>> >> >> Alien::wxWidgets compiler / platforms tested support matrix. For example: >> On Linux, Alien::wxWidgets links to libs or from source. Supports only >> gcc? >> On win32, gcc or VC++ cl (ActivePerl). Only gcc on strawberry and Cygwin. >> On Mac, only gcc also? >> >>>> - How can one could 'require Alien::wxWidgets;' and then call >>>> Alien::wxWidgets->compiler without a 'use Alien::wxWidgets' it? >>>> >>>> Please note that I am asking about the supported configurations to >>>> develop a proper Wx::Scintilla test plan. Hopefully, I will get more >>>> tester reports for Wx::Scintilla on different platforms. >>>> >>>> P.S. I need PAUSE *co-maintainer permission* on Wx::Event so I can >>>> extend it without the PAUSE indexer complaints. >>> >>> you can also defeat indexer by splitting the package line >>> >>> package >>> >>> Wx::Event; >>> >> >> Fixed in 0.09. Thanks for the tip :) >> >>> alternatively, you can add your events in your XS code - which may be the >>> preferred way for new stuff. See Wx source >>> ext/richtext/RichText.xs >>> >> >> Thanks, I will take a look at it. >> >>> Hope it helps. >>> >>> Mark >>> >>> >> >> It helped a lot. >> >> Thanks, :) >> Ahmad M. Zawawi >
