How best to submit upgrade of CURL?

[ned14]

At work we badly needed a modern curl, so I went and merged latest curl 7.74 into the hunter branch: https://github.com/ned14/curl/tree/hunter-7.74.0

Because latest curl uses latest hunter which comes with OpenSSL 1.1 instead of 0.98, I also had to upgrade libssh2 to latest 1.9.0: https://github.com/ned14/libssh2/tree/hunter-1.9.0

Finally, these then broke libs3, so I had to fix that too: https://github.com/ned14/libs3/tree/hunter-4.1.0-p2

My concern here is that if I update libssh2, existing curl will break unless I use hunter config version pins. So what process ought I follow here? How does one go about submitting upgrades to three libraries at once without doing each individually?

[rbsheth]

You can just not upgrade the defaults until the dependencies are ready.

[ned14]

You can just not upgrade the defaults until the dependencies are ready.

Ok, so do I submit PR's for each of libssh2, curl and libs3 first? Once all are accepted and get their own branch, only then do I raise the PR against hunter with updated default versions for all three libraries? Then all three get tested together on CI, and you'll know if my triple set of upgrades are good?

[rbsheth]

Let's upgrade each and set the defaults as normal. CI will go through and then we can decide to revert the default before merge to defer it. Sounds good?

[ned14]

Be aware that if we upgrade libssh2 and change the default, the existing curl will fail to compile. Equally, the upgraded curl will fail to compile unless we do change the default.

This is why I raised this problem here before I begin, because I think you'll need to accept that cpp-pm will become broken for a short while.

Anyway, I've gone ahead and opened the PRs for all three libraries. I appreciate that reviewing the changes will take a while, so let me know when you're done with all three, then I'll prepare the hunter PR.

[rbsheth]

I'm aware of that, but we can just avoid making a release until all the changes have landed. I appreciate the thought that went into the sequencing!

Let's get these changes in and see what happens...

[ned14]

I'll just link to each of the PRs here to save people from having to refind them constantly:

• Rebase hunter curl fork onto curl 7.74.0 curl#1
• Rebase hunter fork onto libssh2 1.9.0 libssh2#1
• Fixes for libcurl upgrade. libs3#2

[rbsheth]

@ned14 Happy new year! Here are all the releases:

https://github.com/cpp-pm/libssh2/releases/tag/v1.9.0-p0
https://github.com/cpp-pm/curl/releases/tag/v7.74.0-p0
https://github.com/cpp-pm/libs3/releases/tag/v4.1.0-287e4be-p1

[ned14]

The PR can be found at #336

hunter-testing appears to no longer be used, so I'm assuming the hunter github actions "do the right thing"?

[rbsheth]

The PR can be found at #336

You need to add the versions to each project's hunter.cmake file in that PR.

hunter-testing appears to no longer be used, so I'm assuming the hunter github actions "do the right thing"?

Correct, in fact batching all updates will allow for them to be tested together.

[ned14]

Ok, the remaining CI failures are in CURL in these matrix items:

• Android NDK builds
• All the Windows builds
• Some, but not all, of the Mac OS builds.

... and all are of the form:

try_compile:
  Cannot copy output executable

    ''

  to destination specified by COPY_FILE:

The problem is that the path try_compile() is trying to copy to does not exist i.e. it chose a non-existent path. What's really weird is that earlier on in the cmake, try_compile() works just fine, but at some later point it stops working.

Note that the Windows builds work perfectly on my machine here.

I'm going to propose that I don't think that these failures are ones I can fix? If you read the many cases where the same thing happens off Google, it appears to almost always be a mistake in the compiler or toolchain configuration which causes this. The general recommendations tend of be of the forms of to wipe your build directory, use a toolchain file instead of command line cmake variable overrides or environment variables, and generally when people change up how they configure cmake, the problem resolves. This particular failure goes back to cmake 2.8 days, and the cmake developers generally respond "you're using cmake wrong" and insta-close the bug report.

I've examined your github actions CI scripts and nothing leaps out at me as an obvious cause.

Not sure what to do next?

[rbsheth]

Weird that the Windows builds work on your machine but don't in CI. Can you check the older version of CURL that we have and see if it has the same problem? You can open a dummy PR.

[ned14]

So, judging from #340, there must be something which either upstream CURL's merged CMakeLists is doing, or a bad merge by me, which is causing the failures in #336. Sigh. It's never easy ...

I'll see if I can carve out some time next week to deep dive on the cause. As I mentioned, it works here just fine, so I expect this to be painful.

[ned14]

BTW note cpp-pm/curl#2. No idea if that fixes the problem, but worth a try.