On Fri, Aug 23, 2013 at 11:35 AM, Bert Huijben <b...@qqmail.nl> wrote: > > >> -----Original Message----- >> From: Johan Corveleyn [mailto:jcor...@gmail.com] >> Sent: donderdag 22 augustus 2013 23:24 >> To: Subversion Development >> Cc: jbl...@gmail.com; Greg Stein >> Subject: Re: Error compiling with serf 1.3.1 on Windows >> >> On Tue, Aug 20, 2013 at 1:07 AM, Johan Corveleyn <jcor...@gmail.com> >> wrote: >> > On Mon, Aug 19, 2013 at 11:03 PM, Greg Stein <gst...@gmail.com> wrote: >> >> On Mon, Aug 19, 2013 at 3:39 PM, Johan Corveleyn <jcor...@gmail.com> >> wrote: >> >>> When I try to build trunk (@now) with serf 1.3.1 on Win XP (with VS >> >>> 2010), I get the following error: >> >>> >> >>> [[[ >> >>> NMAKE : fatal error U1052: file 'serf.mak' not found >> >>> [C:\research\svn\client_build\svn_deps\serf-1.3.1\serf.vcxproj] >> >>> C:\Program >> Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): >> >>> error MSB3073: The command ""c:\Program Files\Microsoft Visual Studio >> >>> 10.0\VC\bin\nmake.exe" /s /nologo /f serf.mak ALL >> >>> APR_SRC=..\httpd-2.4.4\srclib\apr >> >>> APRUTIL_SRC=..\httpd-2.4.4\srclib\apr-util ZLIB_SRC=..\zlib-1.2.8 >> >>> OPENSSL_SRC=..\openssl-1.0.1e " exited with code 2. >> >>> [C:\research\svn\client_build\svn_deps\serf-1.3.1\serf.vcxproj] >> >>> ]]] >> >>> >> >>> Is anyone else seeing this? Perhaps something needs to be updated in >> >>> gen-make.py since the new serf? >> >>> >> >>> This is the gen-make.py command I used: >> >>> [[[ >> >>> python gen-make.py --release >> >>> > --with-junit=C:\research\svn\client_build\svn_deps\junit-4.10\junit.jar >> >>> --with-httpd=C:\research\svn\client_build\svn_deps\httpd-2.4.4 >> >>> --with-serf=C:\research\svn\client_build\svn_deps\serf-1.3.1 >> >>> --with-openssl=C:\research\svn\client_build\svn_deps\openssl-1.0.1e >> >>> --with-sqlite=C:\research\svn\client_build\svn_deps\sqlite- >> amalgamation-3.7.17 >> >>> --enable-ml --with-zlib=C:\research\svn\client_build\svn_deps\zlib- >> 1.2.8 >> >>> --vsnet-version=2010 -t vcproj >> >>> ]]] >> >>> >> >>> Building with serf 1.2.1 still works fine for me. >> >>> >> >> Answer: Subversion should not try to build serf. It should assume serf >> >> has already been built and installed somewhere. >> >> >> >> In general, we should stop building dependencies, except when we >> embed >> >> the sqlite amalgamation. >> >> >> >> [ btw: serf 1.3.x uses scons to build; serf.mak is gone ] >> >> >> >> Cheers, >> >> -g >> >> >> > Okay, I succeeded in building serf 1.3.1 by executing: >> > >> > scons APR=..\httpd-2.4.4\srclib\apr >> > APU=..\httpd-2.4.4\srclib\apr-util OPENSSL=..\openssl-1.0.1e >> > ZLIB=..\zlib-1.2.8 >> > >> > But I don't know enough about the svn build system to teach it not to >> > try building serf itself. So I still get the same error. >> > >> > I hope someone else can make the necessary changes to the (windows) >> > build generator for this. >> > >> >> FWIW, this seems to do the trick for me to be able to compile svn on >> Windows with serf 1.3.1: >> >> 1) Build serf separately with scons (with the command below). >> >> 2) Apply following patch to build/generator/gen_win_dependencies.py, >> so the svn build will no longer try to build serf itself. >> >> [[[ >> Index: build/generator/gen_win_dependencies.py >> ========================================================== >> ========= >> --- build/generator/gen_win_dependencies.py (revision 1516605) >> +++ build/generator/gen_win_dependencies.py (working copy) >> @@ -1033,10 +1033,12 @@ class >> GenDependenciesBase(gen_base.GeneratorBase): >> if version < (1, 3, 0): >> lib_dir = os.path.join(self.serf_path, 'Release') >> debug_lib_dir = os.path.join(self.serf_path, 'Debug') >> + is_src = True >> else: >> lib_dir = self.serf_path >> debug_lib_dir = None >> - is_src = True >> + inc_dir = self.serf_path >> + is_src = False >> elif os.path.isfile(os.path.join(self.serf_path, > 'include/serf-1/serf.h')): >> # Install layout >> inc_dir = os.path.join(self.serf_path, 'include/serf-1') >> ]]] > > The patch looks good.
Okay, committed in r1517192. > >> >> I have no idea if this is the right way to fix this, but it does the >> trick for me. >> >> Now I can at least test the upcoming 1.8.3 with serf 1.3.1 :-). > > This won't help you for 1.8 :( > > The separation of the dependency parser is new for 1.9. We still need a > separate patch for 1.8 (via a branch). I've seen your branch for this. Thanks. I'll give it a try. -- Johan
