February 2010 - Wine-Devel - list.winehq.org

Fw: Re: Unable to Compile Wine on MacOSX

by James Mckenzie

-----Forwarded Message----- >From: James Mckenzie <jjmckenzie51(a)earthlink.net> >Sent: Feb 25, 2010 6:52 AM >To: Charles Davis <cdavis(a)mymail.mines.edu> >Subject: Re: Unable to Compile Wine on MacOSX > >>James McKenzie wrote: >>> Interestingly enough, I have run into the 'Unable to compile' problem >>> building the latest git on MacOSX. Maybe there is corruption in my git >>> pull, but this started yesterday.... >>> >>> It appears that configure never fully finishes and config.status loops. >>I don't have that problem... And I've been experimenting with clang as >>my compiler! >> >>By the way, I never use git pull. I always do git fetch; git rebase >>origin, which is what you're supposed to do anyway if you have local >>patches in your tree. >> >That is what I have been doing. What I may need to do is run git clone and get a new copy. For some strange reason my git copy gets corrupted and I have to do a new 'pull'. > >>Another thing I do is run autoreconf, because I have local changes to >>configure.ac in my tree. That might have something to do with it. >> >Hmmm... > >>I have noticed a change in configure behavior, though. config.status >>creates the makefiles during make, not configure. I find that odd, but >>it still works, so I'm happy. >I'm thinking that both were running and that was causing problems as the first pass finished and then a second one started up. > >At least you confirmed this is 'normal'. > >James McKenzie Send to list as well. Can anyone confirm that this changed with either yesterday's or Monday's git? Thank you. James McKenzie

Feb. 25, 2010

Re: Preferred way of dll registration

by Jacek Caban

Hi Paul, On 2/25/10 11:43 AM, Paul Vriens wrote: > Hi Jacek, > > On 02/24/2010 09:30 PM, Jacek Caban wrote: >> Hi Paul, >> >> On 2/24/10 8:59 PM, Paul Vriens wrote: >>> Hi, >>> >>> We seem to have 2 different approaches for dll registration: >>> >>> 1) a regsvr.c file with all the necessary functions and registry >>> information. >>> 2) an inf file and some code to register/unregister the dll. >> >> 3) IRegistrar from atl.dll > > I see you already sent some atl patches ;) I just took a look how its implementation looks these days and saw some obvious bugs. They won't matter for using IRegistrar in Wine registration code. >>> The first one is the most common in our source but I can remember a >>> comment from AJ about favoring the latter (or at least something like >>> "maybe we should start using inf files for registration"). >>> >>> Thoughts? >> >> I think both 2) and 3) are way better than regsvr.c. It avoids code >> duplication and you can add much more custom registries without a single >> line of C (I'd call it more flexible, but it's more a better >> flexibility/efforts factor). IRegistrar is much simplier than .inf >> parser, so it has fewer builtin features. Most useful things may be >> handled IRegistrar and very simple code in DllRegisterServer >> implementation to pass some string replacements. Using it would also > > The registration in atl is currently with some 'hardcoded' values in > the C-files. Wouldn't it be beneficiary to move these strings to the > atl.rgs file? Than you wouldn't truly need a line of C code when > things need to be changed? I prefer not to duplicate CLSIDs and have them hardcoded in one place. It may avoid some typos and make make .inf/.rgs files nicer, but I don't feel strong about. > The above is not really an issue of course if we have autogenerated > code for the registration. Right. Jacek

Feb. 25, 2010

Re: shell32: implements shell link's GetCurFile (with tests, fixes bug #21297) [try5]

by Alexandre Julliard

Mikołaj Zalewski <mikolaj(a)zalewski.pl> writes: > @@ -33,6 +33,30 @@ > > #include "shell32_test.h" > > +#define expect_eq_x(expected, actual) \ > + do { \ > + int value = (actual); \ > + ok((expected) == value, "Expected " #actual " to be 0x%x (" #expected ") is 0x%x\n", \ > + (expected), value); \ > + } while (0) > +#define expect_eq_p(expected, actual) \ > + do { \ > + void *value = (actual); \ > + ok((expected) == value, "Expected " #actual " to be %p (" #expected ") is %p\n", \ > + (expected), value); \ > + } while (0) > +#define expect_eq_ws(expected, actual) \ > + do { \ > + LPCWSTR value = (actual); \ > + ok(winetest_strcmpW((expected), value) == 0, "Expected " #actual " to be %s (" #expected ") is %s\n", \ > + wine_dbgstr_w(expected), wine_dbgstr_w(value)); \ > + } while (0) > +#define expect_true(actual) \ > + do { \ > + BOOL value = (actual); \ > + ok(value, "Expected " #actual " to be true, but it isn't\n"); \ > + } while (0) > + That's quite ugly. It doesn't save much code since it's basically a single ok() statement each time, and it makes it harder to fix a test when we find out that it can expect two different values, or that it needs a different printf format. Please avoid that sort of thing. -- Alexandre Julliard julliard(a)winehq.org

Feb. 25, 2010

Re: LinuxTag Berlin - call for projects

by Kai Blin

On Thursday 25 February 2010 12:12:41 Jan Gerrit Möltgen wrote: Hi Jan, > I'm not sure, if this is the right place for my question, but I thought > it's better than the user-list. The LinuxTag in Berlin makes a call for > projects ( http://wiki.linuxtag.org/w/fp:Call_for_Projects ) and in my > oppinion Wine should be represented there. Has somebody already submitted > an application? If yes, I would like to support, otherwise I'd like to > submit an application and would be happy about every helping hand. I don't think anybody has applied yet, at least I don't remember seeing any announcement on this mailing list. I've added Uwe Bonnes to the CC list, I know he used to man the Wine booth at LinuxTag back when it was in Karlsruhe. I'm afraid I won't have time to help out myself, but it currently looks like I'll be spending my vacation time this year travelling to a couple of conferences, so I won't have time left to go to LinuxTag. The downside of not having a job working on open source. ;) Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Feb. 25, 2010

Re: [PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer.

by Joerg-Cyril.Hoehle＠t-systems.com

Charles Davis wrote: >I have noticed a change in configure behavior, though. Me too. On MacOS. Since 1.1.39, Makefiles are created at the rate of ~ 1 per sec. It was much faster in 1.1.38 and before, I estimate ~6 files per second. Anyone to confirm this? >I always do git fetch; git rebase origin I never groked "origin" in git. I use N+1 trees: one only contains git, no checkout ever and I "git fetch" from winehq there. The N others come from git clone --local --shared -n /.../wine.git wine-bisect of this distinguished and read only git tree. That's where I compile, write patches, bisect, keep old versions etc. "git fetch" therein access only the local mirror. I can git-gc, git-fsck, git-rebase, "rm -rf" the N trees at will. After git-fetch, I use git-update-ref refs/heads/master remotes/origin/master Perhaps that's the equivalent of your "git rebase origin"? Now nested git rebase and bisect conflicts can berserk my working trees beyond recognition, I get out with "rm -rf" and still have the pristine 200MB source tree and don't need to download it again. IIRC: du "source tree"/.git ~200MB du "cloned bisect tree"/.git ~5MB du wine compiled tree ~400MB (incl. 5MB .git) du wine install tree ~100MB

Feb. 25, 2010

LinuxTag Berlin - call for projects

by Jan Gerrit Möltgen

Hello together, I'm not sure, if this is the right place for my question, but I thought it's better than the user-list. The LinuxTag in Berlin makes a call for projects ( http://wiki.linuxtag.org/w/fp:Call_for_Projects ) and in my oppinion Wine should be represented there. Has somebody already submitted an application? If yes, I would like to support, otherwise I'd like to submit an application and would be happy about every helping hand. Greetings, Jan Gerrit -- Dipl.-Wirt.-Inf. Jan Gerrit Möltgen . . . . . .gerrit.moeltgen(a)itomig.de ITOMIG GmbH . . . . . . . . . . . . . . . . . . Tel.: +49 7031 389 25 06 Otto-Lilienthal-Str. 36 . . . . . . . . . . . . . . http://www.itomig.de D-71034 Böblingen . . . . . . . . . . . . . . . http://www.itomig.de/fr Geschäftsführer: David Gümbel . . . . . HRB 728519 Amtsgericht Stuttgart Sitz der Gesellschaft: Böblingen . . . . . . . . . . . . . . . . . . . .

Feb. 25, 2010

Re: Preferred way of dll registration

by Paul Vriens

Hi Jacek, On 02/24/2010 09:30 PM, Jacek Caban wrote: > Hi Paul, > > On 2/24/10 8:59 PM, Paul Vriens wrote: >> Hi, >> >> We seem to have 2 different approaches for dll registration: >> >> 1) a regsvr.c file with all the necessary functions and registry >> information. >> 2) an inf file and some code to register/unregister the dll. > > 3) IRegistrar from atl.dll I see you already sent some atl patches ;) > >> The first one is the most common in our source but I can remember a >> comment from AJ about favoring the latter (or at least something like >> "maybe we should start using inf files for registration"). >> >> Thoughts? > > I think both 2) and 3) are way better than regsvr.c. It avoids code > duplication and you can add much more custom registries without a single > line of C (I'd call it more flexible, but it's more a better > flexibility/efforts factor). IRegistrar is much simplier than .inf > parser, so it has fewer builtin features. Most useful things may be > handled IRegistrar and very simple code in DllRegisterServer > implementation to pass some string replacements. Using it would also The registration in atl is currently with some 'hardcoded' values in the C-files. Wouldn't it be beneficiary to move these strings to the atl.rgs file? Than you wouldn't truly need a line of C code when things need to be changed? The above is not really an issue of course if we have autogenerated code for the registration. -- Cheers, Paul.

Feb. 25, 2010

Re: [1/2] cmd: Add test case for bug 18346: cmd "^" escape char

by Paul Vriens

On 02/25/2010 08:35 AM, John Chow wrote: > This patch adds the test case for bug 18346: cmd does not support the > "^" escape character (http://bugs.winehq.org/show_bug.cgi?id=18346) > > The test fails on Wine but passes on WineTestBot. > > -John Chow > > You forgot the patch (and also in the second mail). -- Cheers, Paul.

Feb. 25, 2010

Re: Unable to Compile Wine on MacOSX

by Charles Davis

James McKenzie wrote: > Interestingly enough, I have run into the 'Unable to compile' problem > building the latest git on MacOSX. Maybe there is corruption in my git > pull, but this started yesterday.... > > It appears that configure never fully finishes and config.status loops. I don't have that problem... And I've been experimenting with clang as my compiler! By the way, I never use git pull. I always do git fetch; git rebase origin, which is what you're supposed to do anyway if you have local patches in your tree. Another thing I do is run autoreconf, because I have local changes to configure.ac in my tree. That might have something to do with it. I have noticed a change in configure behavior, though. config.status creates the makefiles during make, not configure. I find that odd, but it still works, so I'm happy. Chip

Feb. 25, 2010

Unable to Compile Wine on MacOSX

by James McKenzie

Interestingly enough, I have run into the 'Unable to compile' problem building the latest git on MacOSX. Maybe there is corruption in my git pull, but this started yesterday.... It appears that configure never fully finishes and config.status loops. James McKenzie

Feb. 25, 2010