> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
> Sent: donderdag 22 augustus 2013 23:24
> To: Subversion Development
> Cc: jblond_at_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 <jcorvel_at_gmail.com>
> wrote:
> > On Mon, Aug 19, 2013 at 11:03 PM, Greg Stein <gstein_at_gmail.com> wrote:
> >> On Mon, Aug 19, 2013 at 3:39 PM, Johan Corveleyn <jcorvel_at_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.
>
> 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).
Bert
Received on 2013-08-23 11:36:35 CEST