Menu
▾
▴
perl-win32-gui-hackers — Hacking and developing the Win32::GUI Perl extension
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(31) |
Dec
(80) |
| 2004 |
Jan
(30) |
Feb
(31) |
Mar
(46) |
Apr
(31) |
May
(48) |
Jun
(16) |
Jul
|
Aug
|
Sep
(20) |
Oct
(31) |
Nov
(13) |
Dec
(1) |
| 2005 |
Jan
(4) |
Feb
(7) |
Mar
|
Apr
(3) |
May
(1) |
Jun
(37) |
Jul
(39) |
Aug
(22) |
Sep
(3) |
Oct
(48) |
Nov
(24) |
Dec
(31) |
| 2006 |
Jan
(4) |
Feb
(6) |
Mar
(19) |
Apr
(17) |
May
(39) |
Jun
(62) |
Jul
(11) |
Aug
(21) |
Sep
(10) |
Oct
(26) |
Nov
(8) |
Dec
|
| 2007 |
Jan
(7) |
Feb
(6) |
Mar
(2) |
Apr
|
May
|
Jun
(4) |
Jul
(10) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(2) |
| 2008 |
Jan
(19) |
Feb
(24) |
Mar
|
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Robert M. <rm...@po...> - 2005-07-01 23:05:26
|
Glenn Linderman wrote:
> Hmmmm. Having problems with compiling math.h, I tried this, but got
>
> cl -c -nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE
> -DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED -DPERL_IMPLICIT_CONTEXT
> -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi
> -DNDEBUG -O1 -DVERSION=\"1.01_03\" -DXS_VERSION=\"1.01_03\"
> "-IC:\Perl\lib\CORE" GUI.cpp
> GUI.cpp
>
> *** Using Preserved Perl context.
>
> GUI.xs(200) : error C2065: '__TEMP_WORD' : undeclared identifier
> GUI.xs(288) : error C2065: 'IDI_DEFAULTICON' : undeclared identifier
> GUI.xs(328) : error C2065: 'IDC_HSPLIT' : undeclared identifier
> GUI.xs(331) : error C2065: 'IDC_VSPLIT' : undeclared identifier
> GUI.xs(4465) : error C2146: syntax error : missing ';' before
> identifier 'cClrBits'
> GUI.xs(4465) : error C2065: 'cClrBits' : undeclared identifier
> GUI.xs(4517) : error C2146: syntax error : missing ')' before
> identifier 'pbih'
> GUI.xs(4517) : error C2059: syntax error : ')'
> GUI.xs(4517) : error C2143: syntax error : missing ';' before '{'
> *** PACKAGE Win32::GUI::Menu...
> *** PACKAGE Win32::GUI::MenuButton...
> *** PACKAGE Win32::GUI::MenuItem...
> NMAKE : fatal error U1077: 'cl' : return code '0x2'
> Stop.
>
>
> I think that is an improvement, in the sense that the compilation
> proceeded further than before.
I'm working on it. I think I understand all the changes that Reini gave
me as parts of the cygwi and his MSVC6 patches. I'm reverting GUI.h to
something much closer to what went out with the V1.0 release.
The problems all stem from the 'extern "C"' declarations around the perl
includes - Reini changed the conditions under which they were/were not
defined, resulting in them being added for builds usin
-DPERL_IMPLICIT_CONTEXT, when they were not before; he then added
math.h outside this block, so that when math.h was included again by
perl.h in had already been seen, and was not parsed in "C" context.
I think I've got it going - give me another 15 minutes and I'll check in
an updated version.
Rob.
|
|
From: Reini U. <ru...@x-...> - 2005-07-01 14:20:22
|
> I'll try now to write some basic framework to test all controls for ini,
> some easy methods and properties.
> Win32::GuiTest for dialogs and menus later.
Attached is the start of the coverage methods:
$W->Add$ctrl(), $W->-name, $ctrl->DESTROY()
(AddCtrl methods, is correctly attached and destroyed)
and some parts of the seperate new $ctrl() methods.
I have to leave my work computer now and continue over the weekend
at home.
|
|
From: Reini U. <ru...@x-...> - 2005-07-01 13:06:18
|
now using Test::More I'll try now to write some basic framework to test all controls for ini, some easy methods and properties. Win32::GuiTest for dialogs and menus later. |
|
From: Reini U. <ru...@x-...> - 2005-07-01 11:15:28
|
A minor TODO patch |
|
From: Reini U. <ru...@x-...> - 2005-07-01 09:51:51
|
Robert, Please revert my GetWindowInfo removal for MSVC6. I've found out that not including <winuser.h> fixes the declaration of GetWindowInfo() on MSVC6 |
|
From: Jeremy W. <jez...@ho...> - 2005-07-01 09:44:33
|
>>Does anyone have any experience with any of the GUI test packages that >>actually allow you to interact with a GUI in test, and if so what would >>people recommend? > >I work professionally as tester. GUI testing is part of my job :) (AutoIt, >Win32::GuiTest and Rational Robot) Testing GUI apps can be a pain to do correctly, so it's good that we've got someone who knows what they are doing:) >I'll write down my ideas and which module would fit best. >The module (e.g. Win32::GuiTest) should be optional. It would be nice if we could use Win32::GuiTest simply because it's free and open:) But I don't know enough about the options to contribute. Leaving aside GUI testing, there is still quite a bit that could be done via the command line - things like testing destruction of controls/windows, creating lots of controls, testing for memory leaks etc. Cheers, jez. |
|
From: Johan L. <jo...@Da...> - 2005-07-01 07:28:05
|
At 01:01 2005-07-01, Robert May wrote: >For Reini and anyone else who wants it I have replace the RC2 source with >RC3 source at http://www.robmay.me.uk/win32gui/ It compiles fine with: This is perl, v5.8.6 built for MSWin32-x86-multi-thread WinXP Visual Studion 6.0 /J -------- ------ ---- --- -- -- -- - - - - - Johan Lindström Sourcerer @ Boss Casinos johanl AT DarSerMan.com Latest bookmark: "TCP Connection Passing" http://tcpcp.sourceforge.net/ dmoz: /Computers/Programming/Languages/JavaScript/ 12 |
|
From: Reini U. <ru...@x-...> - 2005-07-01 06:08:36
|
Robert May schrieb: > There has been some talk about improving the test suite recently. I was > thinking that we should have a discussion and try to come to a consensus > about the test tools/frameworks that w should be using before anyone > really starts coding in earnest. > > I think it goes without saying that we want to use the standard perl > test framework and test harness. > > I had it in my mind that I would use the Test::More framework to > re-write what was already there, as well as add tests for each package > existing and creating objects of the right class - it would be a start > at least. > > Does anyone have any experience with any of the GUI test packages that > actually allow you to interact with a GUI in test, and if so what would > people recommend? I work professionally as tester. GUI testing is part of my job :) (AutoIt, Win32::GuiTest and Rational Robot) I'll write down my ideas and which module would fit best. The module (e.g. Win32::GuiTest) should be optional. -- Reini Urban |
|
From: Reini U. <ru...@x-...> - 2005-07-01 06:01:40
|
>> I have, today, built and run 'make test' (although no more than that) >> successfully in the following environments: >> (1) Win98, MinGW (gcc v3.2.3), ActivePerl 5.6.1 >> (2) Win98, MinGW (gcc v3.2.3), ActivePerl 5.8.7 >> (3) Win2k, MSVC++ 2003 Toolkit (cl v13.10.3077), ActivePerl 5.6.1 >> (4) Win2k, MSVC++ 2003 Toolkit (cl v13.10.3077), ActivePerl 5.8.7 >> (5) Win2k, Cygwin (gcc v3.4.4), Perl 5.8.6 To add: I also tested against (6) Win2k, MSVC6 no SP and SP2 (cl 1200), ActivePerl 5.8.7 (7) Win2k, MSVC6 SP2 (cl 1200), ActivePerl 5.6.1 Hopefully I can test against some older perls of mine also sooner or later. Hmm, CVS works for my MSVC6 12.00.8804, ActivePerl 5.6.1 Maybe the math.h logic must be enhanced to be included also on newer versions. They still didn't guard the templates against extern C linkage. So I suggest to use #if defined(_MSC_VER) #include <math.h> #endif Also note that the GUI.res file is incompatible between windres and rc, MS LINK.EXE even crashes with an internal error when linking against the windres file. >> If there are no issues, then I propose that we turn this into a >> release at the start of next week I have also just realised that >> these release candidates should have been numbered 1.00_XX - I guess >> the release should really be v1.02 to keep the numbers increasing :-) > > > Well, I have an issue. Configuration: > > Win2k SP4, MSVC++ 6.0, MSVC++ Toolkit 2003, ActivePerl 5.8.4 > > Error: > > cl -c -nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE > -DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED -DPERL_IMPLICIT_CONTEXT > -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DNDEBUG > -O1 -DVERSION=\"1.01_03\" -DXS_VERSION=\"1.01_03\" > "-IC:\Perl\lib\CORE" GUI.cpp > GUI.cpp > C:\PROGRA~1\MICROS~2\VC98\INCLUDE\math.h(514) : error C2894: templates > cannot be declared to have 'C' linkage > > From a clean, working environment from after RC2 (I think, but maybe > RC1) I did the cvs update, and ran the same batch file I'd used to build > it before, and it failed. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ http://phpwiki.org/ |
|
From: Robert M. <rm...@po...> - 2005-06-30 23:05:59
|
There has been some talk about improving the test suite recently. I was thinking that we should have a discussion and try to come to a consensus about the test tools/frameworks that w should be using before anyone really starts coding in earnest. I think it goes without saying that we want to use the standard perl test framework and test harness. I had it in my mind that I would use the Test::More framework to re-write what was already there, as well as add tests for each package existing and creating objects of the right class - it would be a start at least. Does anyone have any experience with any of the GUI test packages that actually allow you to interact with a GUI in test, and if so what would people recommend? Regards, Rob. |
|
From: Robert M. <rm...@po...> - 2005-06-30 23:01:36
|
Robert May wrote: > I have a small number of items that I wish to conclude before a v1.01 > release: > > (1) Merging Reini's cygwin fixes > (2) reverting to a single Makefile. I just checked in a somewhat larger set of changes than I was anticipating. Most of the changes are in GUI.h and Makefile.PL. I would very much appreciate feedback on whether I've broken the build process for anyone or not. The main points: - now builds from CVS in a cygwin environment (although in my tests, there are still a lot of compiler warnings for casts that the compiler considers iffy) - Makefile.PL and Makefile_m.pl have been merged - Makefile.PL now determines the build environment (one of 3 possibles: MSwin32 and VC++, MSWin32 and MinGW, Cygwin). If it doesn't get it right for you I'd like to know. You can force the issue by passing BUILDENV=xxxx on the command line if necessary (read the first bit of Makefile.PL for instructions). - there are a few extra rules in the makefile, particularly related to deleting stuff properly when doing 'make clean' I have, today, built and run 'make test' (although no more than that) successfully in the following environments: (1) Win98, MinGW (gcc v3.2.3), ActivePerl 5.6.1 (2) Win98, MinGW (gcc v3.2.3), ActivePerl 5.8.7 (3) Win2k, MSVC++ 2003 Toolkit (cl v13.10.3077), ActivePerl 5.6.1 (4) Win2k, MSVC++ 2003 Toolkit (cl v13.10.3077), ActivePerl 5.8.7 (5) Win2k, Cygwin (gcc v3.4.4), Perl 5.8.6 If there are no issues, then I propose that we turn this into a release at the start of next week I have also just realised that these release candidates should have been numbered 1.00_XX - I guess the release should really be v1.02 to keep the numbers increasing :-) For Reini and anyone else who wants it I have replace the RC2 source with RC3 source at http://www.robmay.me.uk/win32gui/ Regards, Rob. |
|
From: Robert M. <rm...@po...> - 2005-06-29 23:14:04
|
When building Win32::GUI with MinGW under ActiveState ActivePerl 5.8.6 and 5.8.7 I get a warning from the compiler about "fileno" redefined. This warning can be eliminated by applying the patch described at http://aspn.activestate.com/ASPN/Mail/Message/perl5-porters/2722680 It needs applying to C:\Perl\lib\CORE\win32iop.h (adjust for you perl install location) Patch included below for reference. Regards, Rob. --- win32iop.h Fri Jun 24 14:55:28 2005 +++ win32iop.h Mon Jun 27 21:17:56 2005 @@ -192,4 +192,7 @@ #undef getchar #undef putchar +#endif + +#if defined(__MINGW32__) || defined(__BORLANDC__) #undef fileno #endif |
|
From: Reini U. <ru...@x-...> - 2005-06-29 07:40:04
|
Please file some of the admins a sf.net "Project CVS Services" request. MM complains about that. http://sourceforge.net/tracker/?func=3Dadd&group_id=3D1&atid=3D200001 Category: Project CVS Services Subject: cvs file rename: perl-win32-gui Please: mv perl-win32-gui/Win32-GUI/ToolTip.xs perl-win32-gui/Win32-GUI/Tooltip.x= s |
|
From: Johan L. <jo...@Da...> - 2005-06-29 06:34:35
|
At 01:12 2005-06-29, Robert May wrote: >It's on my list, but it's such a huge task that until I get some time to >think about it I don't really even know where to start. I think that a >sanity check is a more likely short-term goal. Is it something that >you've given any though to? Well, the first test is to just create each control and see that it doesn't blow up today either. Like the RichEdit, we did a really bad QA job there :) I've done that as a regression test in TGL. Then everything that's a bug gets a test so it doesn't come back. /J -------- ------ ---- --- -- -- -- - - - - - Johan Lindström Sourcerer @ Boss Casinos johanl AT DarSerMan.com Latest bookmark: "TCP Connection Passing" http://tcpcp.sourceforge.net/ dmoz: /Computers/Programming/Languages/JavaScript/ 12 |
|
From: Reini U. <ru...@x-...> - 2005-06-29 05:04:06
|
Johan Lindström schrieb: > At 23:15 2005-06-28, Robert May wrote: > And RC1 worked fine btw, the little I tried. We really need a decent > test suite, at the very least a sanity check. I'll think of one. There are enough samples, which could be automated with one of the available GUI testers. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ http://phpwiki.org/ |
|
From: Reini U. <ru...@x-...> - 2005-06-29 05:02:41
|
Robert May schrieb: > Johan Lindström wrote: >> At 23:15 2005-06-28, Robert May wrote: >>> I'm waiting for feedback from Reini before I check the changes into >>> CVS. If you'd like a heads up, there's a snapshot of my working copy >>> source at http://robmay.me.uk/win32gui/. If you do download and >>> compile it, then feedback (as always) appreciated. Please include >>> perl version and compiler type/versions. >> >> >> 403 Forbidden. > > No idea what was going on. There seems to be something a bit > intermittent since lunchtime today, but it seems to be OK again now. > Let me know if you continue to have problems. Again 403 Forbidden. |
|
From: Robert M. <rm...@po...> - 2005-06-28 23:12:39
|
Johan Lindstr=F6m wrote: > At 23:15 2005-06-28, Robert May wrote: > >> I'm waiting for feedback from Reini before I check the changes into=20 >> CVS. If you'd like a heads up, there's a snapshot of my working copy=20 >> source at http://robmay.me.uk/win32gui/. If you do download and=20 >> compile it, then feedback (as always) appreciated. Please include=20 >> perl version and compiler type/versions. > > 403 Forbidden. No idea what was going on. There seems to be something a bit=20 intermittent since lunchtime today, but it seems to be OK again now. =20 Let me know if you continue to have problems. > I'm planning on trying it with MSVC++ 6 if I get the time. That would be great. > And RC1 worked fine btw, the little I tried. We really need a decent=20 > test suite, at the very least a sanity check. It's on my list, but it's such a huge task that until I get some time to=20 think about it I don't really even know where to start. I think that a=20 sanity check is a more likely short-term goal. Is it something that=20 you've given any though to? Rob. |
|
From: Johan L. <jo...@Da...> - 2005-06-28 22:16:52
|
At 23:15 2005-06-28, Robert May wrote: >I'm waiting for feedback from Reini before I check the changes into >CVS. If you'd like a heads up, there's a snapshot of my working copy >source at http://robmay.me.uk/win32gui/. If you do download and compile >it, then feedback (as always) appreciated. Please include perl version >and compiler type/versions. 403 Forbidden. I'm planning on trying it with MSVC++ 6 if I get the time. And RC1 worked fine btw, the little I tried. We really need a decent test suite, at the very least a sanity check. /J |
|
From: Robert M. <rm...@po...> - 2005-06-28 21:16:41
|
Jeremy White wrote: >> Assuming the I get responses from Reini regarding the small number of >> questions I have about his patches quickly, then I think that we'll >> be ready for a V1.01 release in about a week's time. I'll solicit >> further feedback from the users group, but given the current level of >> response (zero from 15 or so downloads) I'm not sure whether an RC2 >> release serves any purpose ... comments? > > With only 15 download, then it's probably not worth having a RC2. If > there are any problems, then they can be fixed quickly. OK, I think I agree. No RC2 PPM distribution. But, I have just rolled Reini's cygwin changes into my local build, and merged Makefile_m.pl and Makefile.PL (this was easier than I expected, really not much different), and I'd like to ensure that it still builds in everyone's environments before we go for a release. I'm waiting for feedback from Reini before I check the changes into CVS. If you'd like a heads up, there's a snapshot of my working copy source at http://robmay.me.uk/win32gui/. If you do download and compile it, then feedback (as always) appreciated. Please include perl version and compiler type/versions. Thanks, Rob. |
|
From: Jeremy W. <jez...@ho...> - 2005-06-28 07:38:15
|
>Assuming the I get responses from Reini regarding the small number of >questions I have about his patches quickly, then I think that we'll be >ready for a V1.01 release in about a week's time. I'll solicit further >feedback from the users group, but given the current level of response >(zero from 15 or so downloads) I'm not sure whether an RC2 release serves >any purpose ... comments? With only 15 download, then it's probably not worth having a RC2. If there are any problems, then they can be fixed quickly. Cheers, jez. |
|
From: Reini U. <ru...@x-...> - 2005-06-28 06:28:07
|
Robert May schrieb: > I have a small number of items that I wish to conclude before a v1.01 > release: > > (1) Merging Reini's cygwin fixes - the changes are small, and really > shouldn't bother anyone. I have most of them merged in my local > workspace, and no problems with either the MinGW or VC++ builds yet. Thanks. I'll get back to you in the afternoon with my comments and counter tests. > (2) reverting to a single Makefile. I propose to merge the Makefile.PL > and Makefile_m.PL files to get us to a stage where the build procedure > is the same for all platforms. Anyone who has downloaded the > documentation change that I made may have discovered that I got a bit > ahead of myself here, and the build instructions in the Readme file > already assume that this has happened. I propose to keep Makefile_m.PL > that will simply call the real Makefile.PL, having added '-MConfig_m' to > the command line, so that those of you with an ingrained methodology > will keep on working fine. > > Assuming the I get responses from Reini regarding the small number of > questions I have about his patches quickly, then I think that we'll be > ready for a V1.01 release in about a week's time. I'll solicit further > feedback from the users group, but given the current level of response > (zero from 15 or so downloads) I'm not sure whether an RC2 release > serves any purpose ... comments? > > Thanks to everyone who has made comments and given help so far. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ http://phpwiki.org/ |
|
From: Robert M. <rm...@po...> - 2005-06-28 00:00:33
|
All, I have a small number of items that I wish to conclude before a v1.01 release: (1) Merging Reini's cygwin fixes - the changes are small, and really shouldn't bother anyone. I have most of them merged in my local workspace, and no problems with either the MinGW or VC++ builds yet. (2) reverting to a single Makefile. I propose to merge the Makefile.PL and Makefile_m.PL files to get us to a stage where the build procedure is the same for all platforms. Anyone who has downloaded the documentation change that I made may have discovered that I got a bit ahead of myself here, and the build instructions in the Readme file already assume that this has happened. I propose to keep Makefile_m.PL that will simply call the real Makefile.PL, having added '-MConfig_m' to the command line, so that those of you with an ingrained methodology will keep on working fine. Assuming the I get responses from Reini regarding the small number of questions I have about his patches quickly, then I think that we'll be ready for a V1.01 release in about a week's time. I'll solicit further feedback from the users group, but given the current level of response (zero from 15 or so downloads) I'm not sure whether an RC2 release serves any purpose ... comments? Thanks to everyone who has made comments and given help so far. Regards, Rob. |
|
From: Johan L. <jo...@Da...> - 2005-06-26 21:50:14
|
At 21:09 2005-06-26, Robert May wrote: >Hope this is of interest to some of you. I am particularly interested in >understanding more about the unresolved symobls, and whether my solutions >are valid ones - any pointer gratefully received. This is great information! (and the other mail) But I think you're narrowcasting too much by posting to this tiny list :) Why don't you post to the per...@li..., and a lot more people would be able to respond? /J |
|
From: Robert M. <rm...@po...> - 2005-06-26 19:09:49
|
Glenn Linderman wrote: > On approximately 6/20/2005 11:29 AM, came the following characters > from the keyboard of Robert May: > >> Glenn Linderman wrote: >> [snipped conversation on the merits of MinGW, VC++ 6.0 and VC++ 7.0 >> (aka .net) >> >>> I believe there are some library changes and such that cause VC++ >>> 6.0 and 7.0 and .net to require different versions of the >>> libraries... and since ActiveState is compiled with 6.0 that it is >>> best to compile XS extensions with 6.0 rather than the newer >>> compilers. Not that it can't be made to work, I think, but that the >>> footprint of required libraries is larger. PAR-built applications >>> could balloon in size, for example, if built with multiple >>> compilers. At least, that I how I understand it. >> >> OK, there's an article discussing the VC 6/7 issues here: >> http://www.perlmonks.org/?node=Free%20MSVC%20tools%20%2B%20Activestate%20to%20compile%20CPAN%20Modules >> >> You need to be able to sort the wheat from the chaff, but I think the >> bottom line is that VC7 links against a new msvcr71.dll. As I see it >> this will have the following effects: >> (1) On a system with the new DLL it will load an extra DLL into >> memory. I may then still not work. >> (2) On a system without the new DLL it will fail to load. > OK, I had a bit of time to play this weekend. The upshot is that I *THINK* I've successfully built both 5.6 and 5.8 PPM's using the free Visual C++ 2003 toolkit. I *THINK* that I've convinced the compiler to link with the regular C runtime, and looking at the 4 builds I now have (MinGW 5.6, 5.8 and VC 5.6, 5.8) and comparing with the previous V1.0 release, then using Process Explorer all runs appear to load exactly the same set of libraries, and exactly the same version numbers (except, of course, perl and Win32:GUI). However, there are a couple of steps that I took in the build process that I still don't exactly understand, so I'm not going to pretend this is ready for the prime time yet. In case anyone else is interested, here is what I've done so far: (1) Download and install Visual C++ 2003 toolkit http://msdn.microsoft.com/visualc/vctoolkit2003/ Download is ~32MB This gives you the optimising compiler (cl.exe) and linker (link.exe), along with some basic header files and libraries. (2) Download and install the Server 2003 platform SDK http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en Various downloads possible - I downloaded the ISO install and burned myself a disk - download size for full SDK ~400MB All you actually need here is enough of the header files and library files to build and link with the common controls that Win32::GUI uses; I didn't have the time to try and work out which bits this was, so left the whole download running. You also need the resource compiler (rc.exe) (3) Get a msvcrt.lib file, to allow us to link with the dynamic multi-threading c run-time library (not included as part of the toolkit) Apparently this is available as part of the .NET SDK download. I couldn't face another huge download for one file, so followed these instructions to build the .lib file from the .dll that we all have in our system32 directory: http://sapdb.2scale.net/moin.cgi/MS_20C_2b_2b_20Toolkit See section on 'msvcrt.lib missing' Put the generated msvcrt.lib into the lib directory of you toolkit install (4) Prepare a command line environment with path, include and lib environment variables set up to point to the bin, include and lib folders of both the toolkit and the platform SDK. (5) Build Win32::GUI Perl Makefile.PL nmake nmake test I had to make the following changes to get the build to work (specifically I ended up with 2 unresolved symbols at the link phase): __fltused - fix resolution by adding the following code to the end of GUI.h. #ifndef __FLTUSED__ #define __FLTUSED__ extern "C" __declspec(selectany) int _fltused=1; #endif __CllMainCRTStartup@12 - fix resolution by adding -noentry to the linker command line (add to LDDLFLAGS in the Makefile). I also changes a few command line options to eliminate warnings. Here are the full set of changes I made to the Makefile: LDDLFLAGS: remove -debug (as I don't need debuggin information) add -noentry (fixes unresolved __DllMainCRTStartup@12 error) CCFLAGS: change -Gf to -GF (eliminates warning) remove -Zi as I don't want debug information remove -O1 (as it is duplicated in OPTIMIZE) OPTIMIZE: remove -MD -DNDEBUG (as these are duplicates from CCFLAGS) remove -Zi as I don't want debug information Hope this is of interest to some of you. I am particularly interested in understanding more about the unresolved symobls, and whether my solutions are valid ones - any pointer gratefully received. Regards, Rob. |
|
From: Robert M. <rm...@po...> - 2005-06-26 18:25:45
|
Glenn Linderman wrote: > On approximately 6/20/2005 11:29 AM, came the following characters > from the keyboard of Robert May: > >> Do we have anyone with VC++ and perl 5.6 who can do the 5.6 build for >> us? If not we might have to go with MinGW for this? > > Again, if someone can step in and point me at documentation for > installing multiple ActiveState Perl versions on one box, and easily > switch between, I'd be glad to give that a whirl... which would enable > me to build for 5.6 as well, I would think. I know people are doing > it, but I've never bothered to figure out how for myself.... I'm > willing to spend a little time on it, but not enough to reinvent it > from scratch! > > This info is probably easily available on some mailing list I'm not > subscribed to! Well, I found snippets of information, but nothing definitive on my searches around the web, so I decided to give it a go myself. It seems pretty straight-forward. Here's what I did on both my WIn98 and W2k boxes: (1) Download the MSI's for the versions you want from ActiveState (in my case 5.6.1 and 5.8.7) (2) Uninstall any current version - this may not be necessary, but I wanted to change the path for the version I had installed. - run the uninstaller from start->settings->control panel->add/remove programs - remove remaining files (C:\Perl and subdirsin my case). It may be worth a look at what's left to build a list of the modules you installed and will need to re-install. - reboot. May not be necessry, but no harm. (3) Install the new versions, changing the install paths. I found that the installer didn't allow me to change the paths on the third screen of the install wizzard unless I went on to the next page, and then went back again. I used the following paths for the installs: C:\Perl\5.6.1 C:\Perl\5.8.7 I didn't install PPM2 for the 5.6.1 version, nor did I install the ISAPI or PerlScript parts. Uncheck the 'set path' option for at least one of the installs (I unchecked it for both, and now have a couple of batch scripts/commnad prompt shortcuts to launch me command line environments with one perl or the other in my path) I also unchecked the 'Create perl file extension association' check box checked on both of the installs. (4) Check your versions: C:\Perl\5.6.1\bin\perl -v C:\Perl\5.8.7\bin\perl -v perl -v (to find out which, if either are found by your path settings) (5) Check your @INC C:\Perl\5.6.1\bin\perl -V C:\Perl\5.8.7\bin\perl -V (6) Add 'site' libs to your @INC (if they are not there) in my case I found that @INC only included the relavent core lib directory. I fixed this by adding 2 new registry values: To HKEY_LOCAL_MACHINE/Software/Perl add 2 new string values (SV). sitelib-5.6.1 with value "C:/Perl/5.6.1/site/lib/" sitelib-5.8.7 with value "C:/Perl/5.8.7/site/lib/" recheck you @INC with perl -V. (6) re-download and install all the extra modules you want. This is your chance to get up to the latest versions of them! If using PPM take care to use the right one, and have the right perl on the path.. I believe that it is possible to configure one PPM to manage multiple installs (ppm help settings - look for 'targets'), but I haven't tried this. I have succesfully built both 5.6 and 5.8 PPMs from the Win32::GUI source under MinGW in this configuration. Let me know if I can provide any more information. Good luck. Rob. |
18 messages has been excluded from this view by a project administrator.
