Re: Building SVN (dependencies) on Windows
From: Adam Humpherys <adam_at_thescripters.com>
Date: Wed, 6 May 2020 08:01:50 -0600
For what it's worth, I was able to get my build environment working based
-- Adam Humpherys On Wed, May 6, 2020 at 4:32 AM <bert_at_qqmail.nl> wrote: > 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, 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 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 >Received on 2020-05-06 16:02:33 CEST
This is an archived mail posted to the Subversion Dev mailing list.