> Martin, you've changed externals/bsddb-4.4.20 with regards to x64
> builds recently -- have you been able to get things working in your
> x64 environments?
I changed the project files so that it will use the x64 compilers
even if no environment variables were set - the original bsddb files
expec
> The other query I had was whether or not I should try a later version
> of BerkeleyDB -- are we committed to 4.4.20 (or 4.4.x?) for 2.6/3.0
> or is it worth investigating newer versions? Martin/Jesus, any
> thoughts on this?
As Greg says: 4.5.x should work fine.
Importing a new version into th
>>> * Replace Windows API calls with wide versions to support unicode
>>> for file names, environment etc.
>> +1. This should be broken into separate tasks for each API.
>
> What are we referring to here? Calling the W versions explicitly and
> using wchar_t for everything, or using the TCHAR/TE
> It's just depends on how you see the tracker. It's not just to "bug"
> tracker anymore, is it? On other projects I've worked with, we had
> separate areas for bugs, features, and tasks. (yes, it's SourceForge.) I
> found it easier to keep organized. However, if this is Python's way, I'm
> not
> Not quite. Items don't automatically end up on a hot list; they must
> explicitly be put on one. I'm not sure how you'd simulate this via
> saved searches. Maybe a combination of a custom keyword *and* a saved
> search would help. However this doesn't scale so well, because
> keywords show u
> New sprint idea: getting all (inc. trunk) the buildbots green by Thursday.
> Anyone interested?
I think the chance to achieve that is close to zero.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
Eric B. schrieb:
> Hi,
>
> I appologize if this is not the right place to post this, but searching
> through the old archives, I ran across the same issue from 3 years ago, but
> I cannot find the resolution to it.
>
> Currently, I am trying to build the python2.4 SRPM from Python.org on a
> C
> I reviewed all the compiler options used by db_static.vcproj -- the
> only thing I needed to bring over was -DDIAGNOSTIC for debug builds.
> Everything else either had no impact and could be safely dropped, or
> conflicted with compiler options used by the rest of the python build
> (function lev
> Removing the dependency on db_static.vcproj and merging the relevant
> source code files into _bsddb.vcproj did the trick -- all x64
> bsddb-related tests now pass. The only issue with this approach is
> that it locks _bsddb.vcproj into 4.4.20. However, considering that
> this approach (i.e. br
