>
>
>>+#
>>+# EXTERNAL TARGETS (NO BUILD NEEDED)
>>+#
>>+
>>+[apr]
>>+type = project
>>+path = apr
>>+libs = mswsock ws2_32 advapi32 rpcrt4 shfolder
>>+
>>+[aprutil]
>>+type = project
>>+path = apr-util
>>+libs = xml apriconv gen_uri_delims
>>+
>>+[apriconv]
>>+type = project
>>+path = apr-iconv
>>+libs = apr
>>
>>
>>
>This can't be right. First, APR doesn't need shfolder.dll; libsvn_subr
>does. Next, you seem to be assuming a static build. For a dynamic build,
>aprutil must depend on apr.
>
>
Haven't managed to get dynamic builds linking yet do to some API stuff,
I planned on adding a static / dynamic switch one the initial stuff gets
in. On this note, aprutil depends on apriconv which depends on apr, if
I make aprutil depend on apr as well, MSVC6 croaks trying to compile
with tons of duplicate defined symbols.
>>+[neon]
>>+type = external
>>+path = neon
>>+sources = neon/src/*.c
>>+cmd = ..\build\win32\build_neon.bat
>>+release = libneon.lib
>>+debug = libneonD.lib
>>
>>
>>
>So I'll have a .dsp generator, but I'll still have to edit
>build_neon.bat to make it link with zlib and openssl? I _said_ I didn't
>want to push everything into gen-make.py, because the Windows build
>scripts will need options like --with-zlib. It would also be nice to be
>able to point to the location of apr, apr-util, apr-iconv, BDB, ... all
>of which is handled by the configure script on Unix, but has to go
>somewhere else on Windows.
>
>
Neon's makefile system is a mess, I've almost considered making a
project for it with build.conf rules for windows builds. Or would you
rather try to hack around the neon project files straight from the author?
>>Index: subversion/libsvn_ra_dav/session.c
>>===================================================================
>>--- subversion/libsvn_ra_dav/session.c (revision 4365)
>>+++ subversion/libsvn_ra_dav/session.c (working copy)
>>@@ -239,7 +239,7 @@
>> *neon_debug = debug;
>> }
>> else
>>- *neon_debug = 0;
>>+ *neon_debug = 1073742335;
>>
>> return SVN_NO_ERROR;
>>}
>>
>>
>>
>What?
>
>
Sorry, that's a left over from tracking down a neon error.
>And a general observation: You hardcode the names and behaviour of the
>build configurations, and templates for the build scripts, in the python
>code. That makes it very hard to a) add new configuratoins, and b)
>change the scripts (or generate scripts for building DLLs, for example).
>
>
The only reason I've done this that you have to be very specific and
define things in a strict order for the output to be parseable by Visual
C++. As far as the new configurations, I've tryed to stay as modular as
I could without causing MSVC load errors.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 14 00:05:26 2003