bzr 1.14 release schedule and manager

[Alexander Belchenko]

John Arbash Meinel пишет:
> Alexander Belchenko wrote:
>> Talden пишет:
>>>> We talked a bit about this on the phone the other day, so I thought I
>>>> would summarize here.
>>>> I'll also mention, by way of background, John's recent post
>>>> http://jam-bazaar.blogspot.com/2009/03/brisbane-core.html summarizing
>>>> what's going on in this branch.
>>> I grabbed the brisbane-core branch (lp:~bzr/bzr/brisbane-core) to have
>>> a play.  I notice there are new dependencies to get the extensions
>>> compiled... and I apparently don't have them (on WindowsXP using GCC).
>>>
>>> Is there a document of what I need to add to build the extensions - I
>>> added zlib after make reported it missing but may have done so
>>> incorrectly, I progressed from errors that were very clearly zlib to
>>> one that reports that -lz was not found which sounds zlibby...
>>>
>>> (keep in mind I've barely touched C/C++ since university and that's a
>>> dozen years or more ago - be gentle with me).
>> I hope someone will update this page for new dependencies:
>> http://bazaar-vcs.org/BzrWin32Installer
>>
>> I saw there is now zlib, lzo, lzma, xdelta, and other players there?
> 
> So we've talked about a lot of possibilities, and we have some optional
> code to play around with them.
> 
> But at the moment, the only "new" dependency is zlib headers. Python
> itself must be compiling against zlib (since they have stuff like the
> "zlib" module, and native support for zip files, which use DEFLATE, etc.)
> 
> That said, when I look at "Python25/libs" I see 'bz2.lib' but I don't
> see 'z.lib' or zlib.lib or a few of the standard variant names.
> 
> Also, looking in "DLLs" I don't see a zlib.dll, so my guess is that
> python may be compiling statically against zlib, and then not sharing
> the headers in "include"... :(
> 
> At the moment, we only make use of zlib.h to have a better "crc32" handling.
> 
> Hmm... it looks like they include crc32 and deflate directly into their
> modules:
> ../Modules/zlib/crc32.c
> 
> So as near as I can tell, they statically compile their own zlib code,
> and then don't give an (easy) way to access it. :(
> 
> I haven't fully deciphered their vcproj files, though. I wonder if we
> couldn't define an "extern crc32(...)" and then still get things to
> compile when binding against the python.lib, but I have the feeling they
> aren't exporting those zlib functions, so you can't get them even with
> your own definitions :(.
> 
> I'd still like to find a way around it, because I know crc32 is in there
> somewhere, just waiting to be used from C code... :)

I've inspected python25.dll with depends utility and don't found any exported
symbol related to zlib.

Also I've googled a bit and found several sources where one can download zlib
as DLL for Windows:

http://zlib.net/   <-- official site provides compiled DLL
http://www.winimage.com/zLibDll/   <-- this package seems to be the right choice for MSVC 2003

Also there is some [old] interesting bug in Python tracker:
http://bugs.python.org/issue229293

Mark, can you shed some light on zlib+win32 problems?