[Linux][Manager][Scripts] Compile linux manager with vcpkg

[talregev]

Compile Linux manager with vcpkg.

Wait for PRs in vcpkg to be merge:

• [wxwidgets] Fix usage, add cmake options microsoft/vcpkg#17111
• [wxwidgets] Fix wx-config --libs output microsoft/vcpkg#18580
• gnome.mkenums generates huge command which causes command line too long error mesonbuild/meson#6710
• [new port] gtk 3.24.34 port microsoft/vcpkg#22201
• [wxwidgets] Fix linux build microsoft/vcpkg#23765
• [wxwidgets] Validate and fix microsoft/vcpkg#24047
• Change to original vcpkg link.

[talregev]

Trying microsoft/vcpkg#18580

[CharlieFenton]

@talregev: Does building with vcpkg provide a way to ensure that a particular version of BOINC can always be built with exactly the same versions of all the dependent libraries? In other words, do older versions of dependent libraries used in earlier releases of BOINC always remain available? This is very important to ensure reproducibility when investigating bug reports from the field.

Because this is important, I have carefully written the Xcode project for each release of BOINC on the Mac to fail if one tries to build it again with a different version of any of the dependent libraries than the ones with which the original release was built. And the current scripts to build the dependent libraries for the Mac in GitHub actions ensure that the CI builds use those same library versions.

[AenBleidd]

@CharlieFenton, in current design we always use the latest version of dependencies. But it's possible to stick with particular version of any dependency: https://devblogs.microsoft.com/cppblog/take-control-of-your-vcpkg-dependencies-with-versioning-support/

[talregev]

exactly the same versions of all the dependent libraries?

You can configure vcpkg to work like this.
For windows, android, and linux we always take the latest. for windows is for 2 years now. and everting work great. not sure why mac need to be different.
Also @AenBleidd can give his opinion here too. He have more experience with vcpkg than I do.

[CharlieFenton]

in current design we always use the latest version of dependencies.

I think that is a big mistake. Any particular version of BOINC should be 100% reproducible. That requires always using the same dependent libraries. As I wrote, this is important for investigating bug reports, among other purposes.

[talregev]

I think that is a big mistake. Any particular version of BOINC should be 100% reproducible. That requires always using the same dependent libraries. As I wrote, this is important for investigating bug reports, among other purposes.

I don't agree with you.
As I say we already work like this and it not hard for us to find bug inside boinc.
Also we have artifacts that save the boinc binaries exactly as it compile.

[talregev]

I have carefully written the Xcode project for each release of BOINC on the Mac to fail if one tries to build it again with a different version of any of the dependent libraries than the ones with which the original release was built.

This is a big mistake. harder to dev like this, and if you expect someone will replace or help you in mac dev, this is needed to change.

[CharlieFenton]

There can be many reasons why a bug is reproducible when built with one version of a dependent library but not with others. I have found problems in almost every version of WxWidgets, for example, and different versions of wxWidgets have had different problems. There can also be more subtle bugs, such as when a bad pointer in BOINC code causes writing to a location in one of the dependent libraries. Since that memory location is in different parts of the code in different library versions, the symptoms may be different.

[AenBleidd]

As I wrote, this is important for investigating bug reports, among other purposes.

And this is still possible to do. It's not a big deal to build BOINC with any version of dependency from vcpkg (at least if this version exists there). In any case, using vcpkg for linux is optional. For Windows we use now the latest version of dependencies, but it's not released yet. Afterwards we can decide to use some particular version of dependencies for release branch, but for master it's easier to use the latest versions and test with them (and fix if necessary). For Android release we haven't use vcpkg yet for release, but we will see how it goes. If there will be any issues - we can always change our flow :)

[CharlieFenton]

I don't agree with you.

I'm not surprised ;=)

This is a big mistake. harder to dev like this, and if you expect someone will replace or help you in mac dev, this is needed to change.

It is not harder at all. As long as the file mac_build/dependencyNames.sh is kept in sync with the Xcode project, the build scripts take care of it automatically.

Over the years, I have found that many versions of the dependent libraries have problems in BOINC and their source files need to be patched before building. (Of course, this is on the Mac; I haven't been involved with setting up dependent libraries on other platforms.) And different versions of the same library have needed different patches. This is another reason I have found it important to ensure consistency in library versions.

I do realize that the entire approach to (and philosophy of) building and distributing software on Linux is very different from that on Windows and Macs. I would say that Linux users and developers have a different culture. as I understand it, a common expectation on Linux is that each user will build applications and libraries themselves for that specific computer. That is the basis for the configure / make approach which originated in UNIX and Linux.

On Windows and Mac, the expectation is that a developer will build the software in such a way that it will be compatible with a range of OS versions, and the computers tend to have fewer variations in their environment. Instead of building using the configure and make approach, developers on these platforms generally use the integrated development environments (IDE) Visual Studio and Xcode. And of course, Microsoft and Apple also have significant cultural and philosophical differences rom each other.

I haven't been paying much attention to how BOINC has been built for MS Windows recently, but in the past Rom Walton prebuilt a set of dependent library for each version of Visual Studio. Anyone building BOINC for Windows used those same prebuilt libraries, which guaranteed that the identical library versions were always used.

[CharlieFenton]

in the past Rom Walton prebuilt a set of dependent library for each version of Visual Studio

Here is the link to those prebuilt libraries.

[AenBleidd]

@CharlieFenton, during the last year, I found no issues with the current approach for Windows. Maybe the issue you're talking about is applicable to OSX only (or even for OSX it's not an issue anymore, and you just overcomplicating things, I believe, some fresh look is needed on all this (I'm not try to blame you or smth like this)). At least I saw no OS dependent patches for dependencies fr any platform except OSX. But I believe, in this case it's just wxWidgets that has quite shitty support of OSX.

but in the past Rom Walton prebuilt a set of dependent library for each version of Visual Studio

And it was a problem: update dependencies in this case is way to harder (and they are too old there). I don't believe someone will decide to build some old version of BOINC for Windows. The latest version you can always build with the latest dependencies as we're doing now. Also, from my experience during last year of extensive usage of vcpkg on my job, I can say that we faced no issues on Windows with vcpkg (at least, no major issues).

Regarding linux, using vcpkg is just another way of BOINC build. I don't believe everyone will switch to use it (remember that linux users usually don't like Microsoft products, even free one ;) ). But from development perspective it's easier, as you don't need to take care about update (especially critical security updates of curl and openssl) of dependencies.

To summarise all above: we're not switching (at least for linux, Android and OSX) the way BOINC built, it's just an alternative method, and it affects build scripts only. For Windows we switched to vcpkg in VS2019 and now it's way more easier to build BOINC.

[CharlieFenton]

we're not switching (at least for linux, Android and OSX) the way BOINC built, it's just an alternative method, and it affects build scripts only.

@AenBleidd Thank you for explaining that. I did not realize it.

You refuse to do new active dev, and you refuse let other people make changes. Why?
If you have strong opinion on how things need to be done, please join to be active dev.

@talregev You have a very good point. I apologize. When you have been working on a project as many years as I have, it can be hard to let go. I need to be better at that.

[talregev]

Wait for PRs in vcpkg to be merge:

• [wxwidgets] Fix usage, add cmake options microsoft/vcpkg#17111
• [wxwidgets] Fix wx-config --libs output microsoft/vcpkg#18580

[talregev]

Ready for review. (Almost a year. Never too late).