On Fri, Aug 23, 2013 at 11:35 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----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.
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
Received on 2013-08-24 22:06:40 CEST