Menu
▾
▴
perl-win32-gui-hackers
|
From: Robert M. <rm...@po...> - 2005-07-01 23:51:23
|
Robert May wrote: > Glenn Linderman wrote: > >> [errors snipped] >> 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. I just checked in an updated GUI.h (along with backing out a few other changes that Reini and I made in the last few days that turned out to be unnecessary). I hope this will let it build for those of you who it built for previously, and also that it still works for Reini. I can confirm that it compiles and 'tests' ok in the 5 environments that I have available. Rob. |
|
From: Robert M. <rm...@po...> - 2005-07-02 01:54:48
|
Glenn Linderman wrote: > On approximately 7/1/2005 4:51 PM, came the following characters from > the keyboard of Robert May: > >> I just checked in an updated GUI.h (along with backing out a few >> other changes that Reini and I made in the last few days that turned >> out to be unnecessary). I hope this will let it build for those of >> you who it built for previously, and also that it still works for Reini. >> >> I can confirm that it compiles and 'tests' ok in the 5 environments >> that I have available. > > And it compiles for me. Testing commencing shortly. Phew! I wasn't 100% convinced by my changes. Just remains to see if it still builds for Reini. Thanks for the feedback Glenn. R. |
|
From: Robert M. <rm...@po...> - 2005-06-13 18:41:40
|
OK. I've stuck up a PPM for ActiveState Perl 5.8 at http://www.robmay.me.uk/win32gui/ It's a build from today's CVS head revision, after I checked in the last few fixes I had in my local repository. I made the following changes before building: - GUI.pm - changed $VERSION to be '1.01_01' (i.e. v1.01 release candidate 1) - GUI.pm - added line $VERSION = eval $VERSION; (see perldoc perlmodstyle) - README.TXT - added some works on installing using PPM and set version/dates For anyone interested, the build steps I took are below. Is there anyone with a V5.6 Perl who would like to see if they can build a corresponding release candidate? Regards, Rob. (1) Create the MinGW Makefile: perl Makefile_m.pl BINARY_LOCATION=Win32-GUI.tar.gz (BINARY_LOCATION is used as the HREF field for CODEBASE in the PPD file) (2) Modify the Makefile to get GUI.ddl size down: (a) remove -g from LDDLFLAGS (b) remove -g -O2 from CCFLAGS (c) change -O2 to -Os in OPTIMIZE (3) Make nmake (4) Create the documentation: cd docs perl dodoc.pl perl dohtml.pl cd .. (5) Copy the html docs to the build tree: mkdir blib\html mkdir blib\html\site mkdir blib\html\site\lib mkdir blib\html\site\lib\Win32 mkdir blib\html\site\lib\Win32\GUI copy docs\html\*.html blib\html\site\lib\Win32\GUI (6) Copy the samples to the build tree mkdir blib\lib\Win32\GUI\demos copy samples\* blib\lib\Win32\GUI\demos (7) create the PPD file nmake ppd (8) Create the distribution tar cvf Win32-GUI.tar blib gzip -9 Win32-GUI.tar (9) Create the Win32::GUI PPM file mkdir Win32-GUI-1.01RC1-PPM-5.8 move Win32-GUI.tar.gz Win32-GUI-1.01RC1-PPM-5.8 move Win32-GUI.ppd Win32-GUI-1.01RC1-PPM-5.8 copy CHANGELOG Win32-GUI-1.01RC1-PPM-5.8\CHANGELOG.TXT copy README.txt Win32-GUI-1.01RC1-PPM-5.8\README.TXT zip -r9 Win32-GUI-1.01RC1-PPM-5.8.zip Win32-GUI-1.01RC1-PPM-5.8 |
|
From: Johan L. <johanl@DarSerMan.com> - 2005-06-13 21:20:20
|
At 20:41 2005-06-13, Robert May wrote: >OK. I've stuck up a PPM for ActiveState Perl 5.8 at >http://www.robmay.me.uk/win32gui/ Well, at least I can confirm that the bug concerning me the most, Perl crashing, seems to be fixed. /J |
|
From: Jeremy W. <jez...@ho...> - 2005-06-14 07:36:24
|
>Is there anyone with a V5.6 Perl who would like to see if they can build a >corresponding release candidate? Yeah, I'll have a go:) Cheers, jez. |
|
From: Robert M. <rm...@po...> - 2005-06-14 18:32:26
|
Robert May wrote: > OK. I've stuck up a PPM for ActiveState Perl 5.8 at > http://www.robmay.me.uk/win32gui/ Thanks to Jez White there's now a PPM for ActiveState Perl 5.6 at the same location. Regards, Rob. |
|
From: Robert M. <rm...@po...> - 2005-06-19 18:29:49
|
Glenn Linderman wrote: > Sorry, I was gone for a week or so. I have MS VC++ 6.0 and know how > to build the package, but not the whole process for release. Would > that still be helpful? (especially regarding the PAR issue?) I only > have Perl 5.8 installed though, and have never played with having > multiple Perls installed... I'd be willing to try installing 5.6 if > someone can show the way to do multiple Perls. Glenn, I'm not really sure what difference using the VC complier makes vs. the MinGW one. I'm certainly happy about the binary compatibility issue, but size of the resulting binary may be the deciding factor. I've got the current HEAD revision from CVS comming in at 979KB - perhaps you would be kind enough to do a build using VC and let us know the size of GUI.dll. In the mean time I'll go to the pain of downloading the SDK and commandline tools from micosoft, and installing them on a WIn2k system so that I can do that build too. Afraid that I can't help with multiple perls, as I've not had to try it yet. Regards, Rob. |
|
From: Robert M. <rm...@po...> - 2005-06-19 22:44:30
|
Glenn Linderman wrote: > On approximately 6/19/2005 11:29 AM, came the following characters > from the keyboard of Robert May: > >> Glenn Linderman wrote: >> >>> Sorry, I was gone for a week or so. I have MS VC++ 6.0 and know how >>> to build the package, but not the whole process for release. Would >>> that still be helpful? (especially regarding the PAR issue?) I only >>> have Perl 5.8 installed though, and have never played with having >>> multiple Perls installed... I'd be willing to try installing 5.6 if >>> someone can show the way to do multiple Perls. >> >> I'm not really sure what difference using the VC complier makes vs. >> the MinGW one. I'm certainly happy about the binary compatibility >> issue, but size of the resulting binary may be the deciding factor. > > Me neither. I offered, because I (1) have VC++ 6.0 and (2) someone > mentioned some possible incompatibility with PAR and MinGW-built GUI. > I have no idea if this is an issue or not, but, I use PAR and GUI > together, so want it to keep working. I am having no troubles with my MinGW build and PAR. I asked for confirmation of the PAR issue on another thread - it may be cygwin related. >> I've got the current HEAD revision from CVS comming in at 979KB - >> perhaps you would be kind enough to do a build using VC and let us >> know the size of GUI.dll. > > OK, I did that.... > > 06/19/2005 02:21p 860,240 GUI.dll > 1 File(s) 860,240 bytes > > So it seems that VC++ is a little more compact for whatever reason. Indeed. I'm not sure what to make of that. >> In the mean time I'll go to the pain of downloading the SDK and >> commandline tools from micosoft, and installing them on a WIn2k >> system so that I can do that build too. > > Hmm. Is MS VC++ 6.0 available from MS as a download? I didn't think > they started that until VC++ 7.0 ... The .net command line tools (no IDE) are available for free download from microsoft at http://msdn.microsoft.com/visualc/vctoolkit2003/ Thanks for your assistance. Rob. |
|
From: Robert M. <rm...@po...> - 2005-06-20 18:29:47
|
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. In either case this is not what we want, and so I think rules out this route. VC5 might be a possibility if there is a free download for that? I think this leaves us with either MinGW or VC6 for the release builds. I'm leaning towards VC6 for the size reasons (there seems to be suggestions that it is better, as ActiveState use it, but I have yet to see convincing arguments for this particular reason). Glenn, when we get to it I assume that you could do the perl 5.8 build. 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? 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. |
|
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: Johan L. <johanl@DarSerMan.com> - 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: Johan L. <johanl@DarSerMan.com> - 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 09:51:51
Attachments:
Win32-GUI-1.01_03.patch
|
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: Reini U. <ru...@x-...> - 2005-07-01 11:15:28
Attachments:
Win32-GUI-1.01_03-TODO.patch
|
A minor TODO patch |
|
From: Reini U. <ru...@x-...> - 2005-07-01 13:06:18
Attachments:
Win32-GUI-1.01_03-t.patch
|
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 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.
|
Thanks for helping keep SourceForge clean.
X