Tim Van Holder wrote:
> Cygwin's perl is in my PATH before the ActiveState one; this prevents
> the Perl version from being found. It's easy to work around, but it
> would be even nicer if the script detected a cygwin perl and warned
> about it specifically (finding /usr/xxx paths instead of X:/foo should
> be enough of a heuristic). Alternatively, instead of using the first
> perl in the PATH, it could walk the path looking for a usable perl
> (kinda like how a autoconf-based configure script does it).
Windows uses the first exe it find in the path. You can't change that.
The only way to work around that would be to read the PATH variable and
try all paths in it on your own.
> Berkeley DB support requires include and lib directories under the
> directory given to --with-berkeley-db; this basically requires an
> installed version (passing the Visual C directory), as the source
> tree has neither directory (it has dbinc and build_win32/Release,
> at least for version 4.4).
Version 4.4 of BDB hasn't been tested thoroughly with Subversion yet.
I'd stick with 4.3 if I were you.
> In addition, a debug build of subversion tries to link with a debug
> library of Berkeley DB, while the configuration only checks whether
> a release build is available - it's not obvious to me that someone
> who wants a debug version of subversion automatically wants a debug
> version of libdb.
If you link a release library with a debug build, you end up with linker
warnings about LIBC or LIBCD, that's because release builds are usually
linked against LIBC, while debug builds are linked against LIBCD. That's
why you should (if you can) always link debug builds with debug libs and
not mix those.
> With a freshly checked-out neon, I get the warning about not being able
> to determine its version. While using .version is probably the best way
> of finding it, a fallback in case .version is missing could be
>
> grep "^Changes in release " <neon>/NEWS | head -1 \
> | sed -e 's/^.* //' -e 's/:$//'
Not everyone has grep installed. If you download the source tarball of
neon, that file is included there.
> This still leaves the problem that the neon svn repository does not
> include config.hw either, but that was created from config.hw.in
> easily enough.
>
> I also ran into some problems with how apr projects are handled. While
> apr does not provide VS.NET/VS2005 projects, it does provide projects
> for Visual Studio 6, which VS.NET/VS2005 are quite capable of upgrading.
> In my case, I had already successfully built apr/apr-iconv/apr-utils,
> so it felt odd that the subversion solution included its own version.
> One issue is that apr.h already defines _CRT_SECURE_NO_DEPRECATE,
> causing lots of warnings about a duplicate definition of that macro.
> With non-0.9.x-branch trees of apr, things go off the rails completely
> (but since only 0.9.x is officially supported that's to be expected).
Are you sure that 0.9.x defines _CRT_SECURE_NO_DEPRECATE? My apr.h
doesn't define that.
> Is there a particular reason why for apr it's not just about finding the
> lib and the headers?
> Also, since neon and apr are in a subversion repository, why not include
> them as externals?
>
> Zlib building is broken for VS2005 - all sorts of deprecated C compiler
> flags are used (warnings only, but still), and zlib 1.2.3 ships with an
> inffas32.asm that cannot be compiled by the ml.exe that ships with
> VS2005. Again a case where it's perfectly possible to build with the
> upgraded project resulting from opening the included VC6 workspace
> in VS2005 (and not using the ASM core).
If you want, you can build zlib without ASM support (just make sure
Subversion doesn't find msasm in the PATH).
Or, you can use the patched inffas32.asm file here:
http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/ext/build/inffas32.asm
instead. That one will build just fine.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 31 17:34:15 2005