I've been using VC6 to test the ruby bindings as I haven't yet succeeded in
building with mingw.
It needs this patch:
--- build/generator/gen_win.py (revision 1454760)
+++ build/generator/gen_win.py (working copy)
@@ -401,7 +401,6 @@
install_targets = [x for x in install_targets
if not (isinstance(x,
- or isinstance(x,
or x.name == '__JAVAHL__'
or x.name ==
or x.name == 'libsvnjavahl')]
--- subversion/include/svn_types.h (revision 1454760)
+++ subversion/include/svn_types.h (working copy)
@@ -29,6 +29,7 @@
/* ### this should go away, but it causes too much breakage right now */
+#include <limits.h> /* for ULONG_MAX */
#include <apr.h> /* for apr_size_t, apr_int64_t, ... */
#include <apr_errno.h> /* for apr_status_t */
--- subversion/libsvn_subr/sysinfo.c (revision 1454760)
+++ subversion/libsvn_subr/sysinfo.c (working copy)
@@ -28,8 +28,14 @@
#define PSAPI_VERSION 1
+#if _MSC_VER > 1200
--- subversion/libsvn_subr/cache-membuffer.c (revision 1454760)
+++ subversion/libsvn_subr/cache-membuffer.c (working copy)
@@ -116,11 +116,11 @@
/* By default, don't create cache segments smaller than this value unless
* the total cache size itself is smaller.
-#define DEFAULT_MIN_SEGMENT_SIZE 0x2000000ull
+#define DEFAULT_MIN_SEGMENT_SIZE 0x2000000ui64
/* The minimum segment size we will allow for multi-segmented caches
-#define MIN_SEGMENT_SIZE 0x10000ull
+#define MIN_SEGMENT_SIZE 0x10000ui64
/* The maximum number of segments allowed. Larger numbers reduce the size
* of each segment, in turn reducing the max size of a cachable item.
@@ -133,7 +133,7 @@
/* As of today, APR won't allocate chunks of 4GB or more. So, limit the
* segment size to slightly below that.
-#define MAX_SEGMENT_SIZE 0xffff0000ull
+#define MAX_SEGMENT_SIZE 0xffff0000ui64
/* We don't mark the initialization status for every group but initialize
* a number of groups at once. That will allow for a very small init flags
Though honestly, I haven't much interest in it once I can get a mingw
On Wed, Mar 13, 2013 at 10:14 AM, Ben Reser <ben_at_reser.org> wrote:
> On Wed, Mar 13, 2013 at 6:59 AM, Branko Čibej <brane_at_wandisco.com> wrote:
> > Nor should you even try to, IMO. There comes a time when it ceases to
> > make any sense to support an old compiler that's been EOL-d a while ago,
> > especially since free versions of newer compilers are available.
> > I would support removing the .dsp generator completely.
> +1, it's old and broke and better to not exist. If it's there someone
> is likely to try to use it.
Received on 2013-03-14 04:36:27 CET