Update cmake project version setting

[dyfer]

We have removed old PROJECT_VERSION_MAJOR etc variables in the main SC repo after version 3.14. This PR switches to use the currently used SC_ variables.

Note that I had to move some lines around, particularly adding modules and checking for SC source, in order to set the project's version early on in the file.

I have not tested changes to the cpack part, but 1) I'm not sure we use this functionality and 2) the version for cpack should be set automatically from the project version.

The new version indicators for the project do not include the "tweak" part (e.g. "-rc1"), except for posting, since cmake does not allow dashes. This is in line with the current implementation in SC's cmake.

I also removed different cmake version setting for supernova and switched it on by default on all platforms (similarly to the current setting in SC).

[Spacechild1]

This doesn't look right to me. On the one hand, sc3-plugins has its own version number (= the git tag), which does not necessarily matches the one of the SC repo. This can lead to situations where sc3-plugins 3.15 might present itself as 3.14 when building against SC 3.14.

I think that we should just report the "real" version, probably via a cmake_modules/version.cmake module similar to SC's SCVersion.txt. Then the message would become something like:

message(STATUS "Building sc3-plugins ${PROJECT_VERSION} against SuperCollider ${SC_VERSION}")

The question: do we mandate that the sc3-plugins matches the SC version? If yes, then we should enforce it!

Personally, I think there are situations where it can make sense to build sc3-plugins against older SC versions. For example, a user might not be able to upgrade their SC installation, but they want to compile a newer version of sc3-plugins to get some bugfixes. As long as it compiles, I don't see any issues with that. After all, sc3-plugins are in maintainance mode and won't use any new features from SC 3.15+.

[dyfer]

I guess so far we didn't really track the sc3-plugins version separately from SC. So indeed, whichever version of SC you build against, this is the version reported by the plugins, at least for display and packaging purposes.

Since sc3-plugins are in maintenance mode, I don't think that's necessarily bad... ultimately it's unlikely the users need to differentiate versions of plugins themselves, but they may need to differentiate versions built against different versions of SC/plugin interface on the same machine.

The project version is also used in the cpack portion - I'm not sure who's using that, but it was similarly set to the SC version. That's why I used the implementation to just set the project version.

Do you think we should change this, particularly considering the maintenance status?

[Spacechild1]

I think that sc3-plugins should report its true version. I find the current behavior really confusing.

but they may need to differentiate versions built against different versions of SC/plugin interface on the same machine.

I don't really see why it should behave differently from "normal" third-party plugins in this regard. For example, VSTPlugin 0.6.2 does not magically turn into VSTPlugin 3.14 just because I build it against SC 3.14 :) If I need to maintain different sc3-plugins builds for different SC versions, I just need to keep them in different folders, just like with all other plugins.

[dyfer]

I understand this is a non-standard behavior. But do we want to change it for what's possibly one last version of sc3-plugins, assuming the package manager comes around and we split plugins into multiple independent packages?

[Spacechild1]

Since you're doing a PR anyway, I would take the chance and fix it. But that's just my opinion.

[dyfer]

Okay. Are you suggesting a version defined in a text file, like in SuperCollider? Or some other way? We can't only rely on a git tag, since the source needs to build from a source tarball as well.

[Spacechild1]

I would just do the same thing as in SCVersion.txt.