Add win bld

[briantoby]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• Selectors are suggested to take a <two spaces>#<one space>[<expression>] form. See lines [17, 18, 25, 26]

[briantoby]

@conda-forge-admin, please rerender

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• Selectors are suggested to take a <two spaces>#<one space>[<expression>] form. See lines [17, 18]

[zklaus]

Nice to see this addition! I am afraid the approach to the compiler problem will be a bit more difficult. I'll explain a bit more in another comment.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[zklaus]

I took the liberty of doing the changes that we discussed myself, I hope you don't mind. You may be surprised to see that I was able to push directly into your repository. This is because when opening the PR you activated a little checkbox that said Allow edits and access to secrets by maintainers, so make sure to fetch or pull those changes before you continue working on this.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• If python is a host requirement, it should be a run requirement.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[zklaus]

@conda-forge-admin, please rerender

[briantoby]

@conda-forge-admin, please rerender

[github-actions]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you, but it looks like there was nothing to do.

This message was generated by GitHub actions workflow run https://github.com/conda-forge/subversion-feedstock/actions/runs/2363583144.

[zklaus]

I'm afraid serf is currently available neither for windows nor osx (see here). I agree that subversion without serf is pretty useless, but it may be worthwhile to get it to build without serf first and then add that later.

[briantoby]

I am stumped on how to address the build windows problems here. The build fails, but other than a warning for header file that should be optional, I don't see any error messages (see https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=510095&view=logs&j=e5cdccbf-4751-5a24-7406-185c9d30d021&t=66e4a587-a723-53e9-873c-6c9a2c5971ea&l=811). I tried unsuccessfully to address the header issue to no avail, but there must be some way to get more information from this.

[zklaus]

I think the problem is https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=510095&view=logs&j=171a126d-c574-5c8c-1269-ff3b989e923d&t=1183ba29-a0b5-5324-8463-2a49ace9e213&l=772, i.e.

C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\VC\v150\Microsoft.Cpp.WindowsSDK.targets(46,5): error MSB8036: The Windows SDK version 8.1 was not found. Install the required version of Windows SDK or change the SDK version in the project property pages or by right-clicking the solution and selecting "Retarget solution". [%SRC_DIR%\build\win32\vcnet-vcproj\svn_config.vcxproj]

There seem to be two possible approaches: Downgrade the SDK or patch the buildsystem to produce a more recent target.

I say more recent because of https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=510095&view=logs&j=171a126d-c574-5c8c-1269-ff3b989e923d&t=1183ba29-a0b5-5324-8463-2a49ace9e213&l=429

Windows SDK version found as: "10.0.22000.0"

My intuition is to go with the latter, but I don't know how to do it.

[zklaus]

Probably we can use something from this page.

[zklaus]

Nice, that seems to have done the trick. The current problem is a recent change in the build tools. Nothing to do but to wait for conda-forge/conda-build-feedstock#176 to be merged.

[zklaus]

The fix is in. We'll have to wait another 2 hours or so for it to propagate through to the cdn.

[briantoby]

Windows build finally succeeded! (at least w/3.9, others still running), but this svn is still pretty brain-dead.

Needs:

• py3c
• serf
• perl bindings(?)

[briantoby]

@zklaus do you think perl bindings are needed for Windows? Is it done the same as on Linux? Will look into serf for Windows and then MacOS.

[zklaus]

The Perl bindings are not needed. I added them even to the UNIX builds relatively recently to support git-svn, but having subversion without that available on Windows will already be helpful, so I am all for merging this without the Perl bindings and adding them in a separate PR later on.

I think your solution of skipping the test is perfect, but would prefer to use a selector of # [not win] so that we do get the tests on osx as well.

You are right to tackle serf on Windows next. I am not sure whether it makes sense to merge this PR without serf or not.

[briantoby]

@zklaus I really don't think there is much value in a subversion package that can't access web repositories via http or https, so as much as I would love to note partial success, I really think that anyone who did install a windows package w/o serf would just think it was a buggy distribution.

My hope is that it will not be too hard to build serf on mac & windows, but I suspect that will not be the case. I did find some tips that may be of help (https://www.mail-archive.com/[email protected]/msg01887.html).

[briantoby]

@zklaus I have some progress on serf. It builds w/openssl1.1.1 (not 3 due to the same problem as you had on MacOS build) but it seems something is wrong either with the self-test (which simply checks for presence of some files) or more likely the packaging. Is there a way to download package created in a pull request? I'd like to see what is inside the package .tar file that is getting created. (answered for me on gitter, see azure in conda_forge_yml docs).

Assuming I do get all that addressed, is it possible to do a test build for subversion using serf from the pull requests to see if svn will work?

[zklaus]

Great work on serf! I am not sure I understand what you mean, but what we definitely can do is activate serf here in the bld.bat, activate the storage of artifacts here, and download the built package from the PR. Then we can test it locally and that should confirm whether it works. Does that make sense and answer your question?

[briantoby]

@zklaus If I understand correctly, it is possible to move forward to use the PR serf builds (w/openssl1.1.1) and this PR. How?

While at it, it would make sense to do the same with the MacOS subversion build, along with your PR for serf.

Finally, do you understand why the Linux serf build works with openssl3 when it does not on other platforms? I would expect it to fail with the same missing routine. While at it, it seems like a pretty trivial change to remove the call to ERR_GET_FUNC from the one place where it is used in buckets/ssl_buckets.c with a patch. Any reason not to do this?

[zklaus]

@zklaus If I understand correctly, it is possible to move forward to use the PR serf builds (w/openssl1.1.1) and this PR. How?

I would finish the serf work (btw, let's discuss any purely serf related issues over there; feel free to tag me there if I don't answer), then we can just use the resulting builds normally, i.e. also in this PR, so nothing special beyond adding serf to the dependencies and adding the required switch to the build script.

While at it, it would make sense to do the same with the MacOS subversion build, along with your PR for serf.

Finally, do you understand why the Linux serf build works with openssl3 when it does not on other platforms? I would expect it to fail with the same missing routine. While at it, it seems like a pretty trivial change to remove the call to ERR_GET_FUNC from the one place where it is used in buckets/ssl_buckets.c with a patch. Any reason not to do this?

Overall, the builds in the serf repo work, as long as one doesn't call scons check 😏 Of course, that doesn't really mean they are working, just that we are not looking closely enough to see them break. With the check in place, some problems are due to the testing code being broken, but some are real problems in the library. My plan has been for some time to look to other packaging efforts (I put a link to the debian patches in the build script in the openssl3 PR) and to port all those patches, but it is a bit non-trivial and I haven't found the time. If you want to make progress there, that would be welcome. Let me know if I need to add you to my fork...

[briantoby]

@zklaus I can see that you want to do some fairly sophisticated things in your serf PR, but I decided to do the minimum just to get it serf build everywhere. That is now ready for testing here. Do I need to set the azure store_build_artifacts flag to get access to the serf builds? Is there a preferred way to introduce them into these builds?

[briantoby]

The windows build fails: it was built with a PR version of serf in PR #16, but svn does not run (it crashes even with a svn -h or svn --version command). Not sure why, but not sure where to go from here.