bzr 1.14 release schedule and manager

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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... :)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknLqB0ACgkQJdeBCYSNAAOAuQCgv7Bke5pGiKOAY5oSkcqsA46K
YroAoIOXjxqwTcoD9730ZJxbLAPvWXV6
=RxRO
-----END PGP SIGNATURE-----