CMake/CI Build Improvements

[emabrey]

• Automatically enable inter-procedural optimization (IPO) on supporting compilers using CMake configuration changes
• Fix 32-bit builds to not redefine compiler/cstdlib internal functions during IPO enabled builds ( as it is not possible because of IPO in-lining)
• Add GitHub CI configuration to use Visual Studio Generator
• Fix incorrect comments/debug messages which incorrectly described the meaning of the IS_64_BIT variable
• Refactor GitHub CI cmake_build.yml workflow configuration to increase readability and maintainability
• Update vcpkg binary cache to use Github Packages
• Change CI builds to create caches by id instead of by name
• Refactor CMakeLists.txt to use consistent formatting and be laid out more logically

I have no idea why, but this seems to have partially resolved the MacOS build problems we've been having with CPack. I have built this several times now and it builds two different jobs on MacOS and initially none of them failed.

Reference-to: https://github.com/tenacityteam/tenacity/pull/198
Resolves https://github.com/tenacityteam/tenacity/issues/526

Checklist

• I have signed off my commits using -s or Signed-off-by* (See: Contributing § DCO)
• I made sure the code compiles on my machine
• I made sure there are no unnecessary changes in the code*
• I made sure the title of the PR reflects the core meaning of the issue you are solving*
• I made sure the commit message(s) contain a description and answer the question "Why do those changes fix that particular issue?" or "Why are those changes really necessary as improvements?"*

* indicates required

[Be-ing]

This PR has a bunch of unrelated changes together. Please split it up so they can be discussed separately.

[emabrey]

This PR has a bunch of unrelated changes together. Please split it up so they can be discussed separately.

No. They are all related fixes that improve the CI build. I'm not doing extra work to split up a bunch of related changes. Additionally, most of them don't work split apart. Please stop making this same comment on every single PR I make. It's not a review, it's not helpful and it's not productive.

[Be-ing]

I don't get how the changes to the GitHub Actions workflow file, many of which I think are steps backwards, have to do with the changes to the other files. I don't want to hold up the improvements like IPO over that.

[emabrey]

I don't get how the changes to the GitHub Actions workflow file, many of which I think are steps backwards, have to do with the changes to the other files. I don't want to hold up the improvements like IPO over that.

If you think that there are problems with the way I improved the cmake_build workflow then you need to be specific.

Here are the things I fixed about that workflow:

• It incorrectly used the job names (which include spaces and are not guaranteed to be unique) instead of the job ID (which are unique and non-spaced) to generate the filenames for the caches

• It failed to specify manually what the job ID should be, so it was being auto-assigned one which is auto-generated and potentially less useful

• It included massive amounts of redundancy and "copy paste" between jobs, all of which destroys readability and maintainability

• It failed to use the CI process to test any CMake generator other than the one you personally prefer

• It failed to centralize multi-step configuration variables and left them strewn out across all the steps

• The packaging step somehow massively increased the prevalence of the timing issues with MacOS because of the use of && instead of placing the CPack directory cleanup/removal command on a separate line

• It used the Artifactory Nuget provider instead of the Github Packages provider, which is a change that ties it implicitly in with the rest of the changes in this PR

• It was using up massive amounts of disk space and getting very close (i.e. within 100MB before I noticed it when it broke the 50MB barrier and generated a warning) to exceeding the maximum allowed space for the CI of 14GB disk usage

[Be-ing]

I was trying to avoid getting into an in depth discussion about all of those points. Most of those are distinct and can be split to separate PRs.

[emabrey]

I was trying to avoid getting into an in depth discussion about all of those points. Most of those are distinct and can be split to separate PRs.

This PR is a general improvement to the CI builds. All the changes implemented are scoped to that idea (improve builds on CI). The IPO changes aren't external to improving CI builds, so they shouldn't be split out. The rule about separate PRs doesn't make sense to apply in this context because what you are actually saying is you want me to split it apart because you don't like some of the improvements and that makes it easier for you to discard some of them by ignoring them (more or less the coding equivalent of a heckler's veto**). That's not what that rule is designed to do. If you can point out how any of the changes don't improve CI builds then I would be happy to consider splitting them out, but currently AFAIK all the changes are in scope to that change premise. Alternatively, if you can point out why you believe that some of the changes that are in scope to this PR are inappropriate or in need of additional changes (i.e., a review), that would also be helpful. The PR splitting procedure is not appropriately used to break a change-set into a bunch of small pieces and then ignore the ones you don't like without providing any actual criticism or review.

Edit: ** Without the connotative implications about being impolite. I'm not implying that.

[emabrey]

I was trying to avoid getting into an in depth discussion about all of those points. Most of those are distinct and can be split to separate PRs.

This PR is a general improvement to the CI builds. All the changes implemented are scoped to that idea (improve builds on CI). The IPO changes aren't external to improving CI builds, so they shouldn't be split out. The rule about separate PRs doesn't make sense to apply in this context because what you are actually saying is you want me to split it apart because you don't like some of the improvements and that makes it easier for you to discard some of them by ignoring them (more or less the coding equivalent of a heckler's veto**). That's not what that rule is designed to do. If you can point out how any of the changes don't improve CI builds then I would be happy to consider splitting them out, but currently AFAIK all the changes are in scope to that change premise. Alternatively, if you can point out why you believe that some of the changes that are in scope to this PR are inappropriate or in need of additional changes (i.e., a review), that would also be helpful. The PR splitting procedure is not appropriately used to break a change-set into a bunch of small pieces and then ignore the ones you don't like without providing any actual criticism or review.

Edit: ** Without the connotative implications about being impolite. I'm not implying that.

The only change that maybe should be split out would be the fix to cmake-modules/FindVampHostSDK.cmake, but I was planning on adding CI configurations to test debug builds in addition to release builds, so it's more like it's related but not as strongly.

[nbsp]

I don't think anything related to DarkAudacity should be touched. If anything, we should remove it outright, but that's outside the scope of this PR.

[nbsp]

I don't think anything related to DarkAudacity should be touched. If anything, we should remove it outright, but that's outside the scope of this PR.

Wait, no, I might've misunderstood the change. Why is a file not related to DarkAudacity whatsoever named darkaudacity.ico?

[Be-ing]

Please stop making this PR even bigger with even more unrelated commits.

[emabrey]

Assuming this last force-push builds successfully I will split this up into separate branches where possible and submit separate PRs.

[emabrey]

Split PRs:

https://github.com/tenacityteam/tenacity/pull/577
https://github.com/tenacityteam/tenacity/pull/578

[emabrey]

I believe this will be fixed once https://github.com/tenacityteam/tenacity/pull/578 is merged and then it can be reviewed without any errors.

[emabrey]

I believe this will be fixed once #578 is merged and then it can be reviewed without any errors.

I was right 😎

[Be-ing]

Whoa wtf? This branch was not approved by anyone!