RE: Building SVN (dependencies) on Windows

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.bloice_at_trihedral.com>
Verzonden: donderdag 23 april 2020 18:17
Aan: dev_at_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