Quite a few of the Windows dependencies can easily be built by the VCPKG 
package manager.

 

For SharpSvn I maintained quite a few custom NAnt scripts that do about the 
same work (https://ctf.open.collab.net/svn/repos/sharpsvn/trunk/imports

(or  <https://github.com/AmpScm/SharpSvn/tree/master/imports> 
https://github.com/AmpScm/SharpSvn/tree/master/imports, but I think this mirror 
lags a bit )

 

Somewhere in the CollabNet open source repositories there should be a slightly 
simpler -not as many development options- MSBuild version of the scripts to 
build the dependencies, but I’m not sure at which url.

 

              Bert

Van: Graham Bloice <graham.blo...@trihedral.com> 
Verzonden: donderdag 23 april 2020 18:17
Aan: dev@subversion.apache.org
Onderwerp: Re: Building SVN (dependencies) on Windows

 

Apologies for butting in, but as a long time maintainer of the (mainly Windows) 
build process for Wireshark, another cross platform project, I'd like to offer 
my thoughts on such matters to the svn project.

1.      We moved to CMake quite some time ago, getting rid of automake and 
nmake and VS solution files.  Such a relief to have one build tool, usable on 
all platforms.  This is obviously a big step to take.
2.      Wireshark has lots of dependencies on 3rd party libraries and on 
Windows the usual issues of obtaining them and where to put them.  The project 
has "solved" this by maintaining an svn repo (even though the project has 
switched to git for the sources) of "-dev" zip packages containing the items 
required to build; headers, .lib and .dll files, e.g.  
https://anonsvn.wireshark.org/wireshark-win64-libs/trunk/packages/    Part of 
the CMake generation step runs a PowerShell script that checks for updates, 
downloads the required zips and expands them to a "known" location, 
configurable by env vars.  The locations of these files are passed as hints to 
the CMake findxxx modules (modified by the project) so that CMake is happy.  
Some build tools and libraries are exclude from this process and have to be 
manually installed, e.g. Perl, Python, Qt.
3.      Production of the "-dev" packages takes a few forms, cross building on 
OpenSUSE or using vcpkg, the details are listed for each library, e.g. 
https://www.wireshark.org/docs/wsdg_html_chunked/ChLibsGLib.html.  When a 
library is updated, a single "tag" file in the main source tree is updated 
causing all builders to check for changes.
4.      All required artefacts are built\copied by CMake directives into the 
run-time directory so tests can be run without requiring installation.
5.      The installers are also built by CMake and pick up the required 
artefacts from the run-time directory.

I see a number of advantages with the Wireshark solution:

1.      Much smaller barrier to entry for those attempting to build.  Still 
quite a setup needed, hence the developer's guide step-by-step section, see 
here:https://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html
2.      No need to build (or even download unless there are changes) the 3rd 
party libraries reducing build times
3.      Consistency across builds for all users, no local variations causing 
oddities.

You can see the sausages being made over at the Wireshark buildbot: 
https://buildbot.wireshark.org/wireshark-master/waterfall, in particular the 
"ran CMake" generation step, although if there are no updates to the libraries 
it's a standard CMake experience.

 

I'm not subscribed to the list, just observe infrequently via the svn.haxx.se 
<http://svn.haxx.se>  archive, so if you have any questions please add me in 
replies.

 

P.S. I did build svn on Windows once, many years ago and I found it an awkward 
process.

 

-- 

Graham Bloice

Reply via email to