set plugin extension to .scx on all platforms

[Spacechild1]

in SC 3.15 the .so extension will be deprecated.

[JordanHendersonMusic]

One question... What happens if the user has the old installed, updates, then rebuilds. What happens to the old files after installing the new ones?

[Spacechild1]

What happens to the old files after installing the new ones?

If installed manually: nothing, the user has to manually remove the old files.

With the official sc3-plugins packages the package manager should be responsible for removing the old files. At least that's what I would think.

[JordanHendersonMusic]

With the official sc3-plugins packages the package manager should be responsible for removing the old files.

I don't really know anything about this, but if you don't uninstall but instead just update, and the file changes, might you still be left with the old file?

What would happen in that case? Would both be loaded?

[Spacechild1]

but if you don't uninstall but instead just update, and the file changes, might you still be left with the old file?

Debian packages have remove scripts that are responsible for removing files before a new version gets installed. If the package maintainer did a good job, the old .so files should be removed before the new .scx files are installed. If that's not the case, users should file an issue to the package maintainer.

What would happen in that case? Would both be loaded?

Both would be loaded, but the user still gets the deprecation warning.

[dyfer]

Uh oh... we haven't gotten around to releasing sc3-plugins version 3.14 and I have just thought to get around to it so that we have version partity and include some minor updates.
I guess we can either 1) skip 3.14 release altogether, if that's okay with everyone, or 2) revert this change, release plugins 3.14 and then bring it back

Also pinging @capital-G so that we have this on our radar.

[dyfer]

Also... shouldn't we check for SC_VERSION here so that the plugins can still be built against older SC source? that way the change won't even be active in CI builds until we merge supercollider's future 3.15 branch into main after the release. That way the current builds of sc3-plugins would still be using the stable (i.e. 3.14) version, which I think should be the case.

EDIT: maybe that is not needed; building against older SC can be done from older tags/source files. But we should make a 3.14 version that uses the old extension.

[Spacechild1]

Uh oh... we haven't gotten around to releasing sc3-plugins version 3.14 and I have just thought to get around to it so that we have version partity and include some minor updates.

Oh, I wasn't aware of that!

Also... shouldn't we check for SC_VERSION here so that the plugins can still be built against older SC source?

What is SC_VERSION? I couldn't find any reference to it.

I assumed that sc3-plugins 3.15 and supercollider 3.15 would be released together. But actually you are right that the two projects don't necessarily have to be in sync. For example, the user might intentionally stay on an older SC version, but still want a newer sc3-plugins version.

So yes, it would be nice if we could get the SC version at runtime and set the plugin extension accordingly. But how do we do that? The only thing we have is SC_PATH, i.e. the path to the source directory.

One possibility would be to parse the git tag of the SC repo, but this means that the user must clone SC from git.

Another idea: compile a simple program that includes include/plugin_interface/SC_InterfaceTable.h and prints out the value of sc_api_version.

Anything else?

[dyfer]

We can access sc version at build time, that's what I'd suggest. It's in SC's CMakeLists.txt and is included in sc3-plugins cmake: https://github.com/supercollider/sc3-plugins/blob/main/CMakeLists.txt#L56-L57

I think something like this should work?

if(${PROJECT_VERSION} VERSION_LESS 3.15 AND NOT WIN32 AND NOT APPLE)
    set(CMAKE_SHARED_MODULE_PREFIX "")
    set(PLUGIN_EXTENSION ".so")
endif()

[Spacechild1]

Ah, so the variable name is PROJECT_VERSION and not SC_VERSION. That's why I was confused.

Actually, I think that SC_VERSION would be a better name because to me PROJECT_VERSION reads like the version of this project (= sc3-plugins). I also think SC_VERSION should be a cache variable so that the user can also set it manually e.g. if they don't have the full SuperCollider repository. Finally, the version detection should be part of the SuperCollider3 find module (https://github.com/supercollider/sc3-plugins/blob/main/cmake_modules/FindSuperCollider3.cmake) so that SC_VERSION is set together with SC_PATH.

Side note: it would be great if sc3-plugins could set a good example and also add a SC_INCLUDE_DIR cache variable that directly points to the header directory. This would allow to build sc3-plugins directly against a pre-installed supercollider-dev package on Linux. The issue is that SC_PATH assumes that the headers are in <SC_PATH>/include/... which is only true for the git repository. On Linux, the headers of supercollider-dev are installed to /usr/include/SuperCollider/... resp. /usr/local/include/SuperCollider/....

I have started adapting my own plugin CMakeLists.txt files in this regard: https://git.iem.at/aoo/aoo/-/blob/develop/sc/CMakeLists.txt?ref_type=heads#L7-28

The basic idea is that SC_INCLUDE_DIR is set automatically by searching the system include dirs. If not found, it is set to <SC_PATH>/include (= relative to the SC source code).

I think something like this should work?

Yes, that looks fine to me.

[dyfer]

Ah, so the variable name is PROJECT_VERSION and not SC_VERSION. That's why I was confused.

SC_VERSION is set in the version file imported from SC: https://github.com/supercollider/supercollider/blob/develop/SCVersion.txt#L8

We are also currently using here PROJECT_VERSION from SC that we removed after 3.14 - I tried to address that in #429. Let's move the discussion there on how to handle the relationship of the version of the plugins vs SC.

Actually, I think that SC_VERSION would be a better name because to me PROJECT_VERSION reads like the version of this project (= sc3-plugins).

Yeah, I think we currently don't really differentiate between the version of the plugins and sc - I'm guessing the assumption is that they should match. Since we don't have a separate numbering for sc3-plugins, I think introducing the differentiation would get confising - "these are plugins v 3.15 built against SC v. 3.14"...? Or do you think this is what we should have?

I also think SC_VERSION should be a cache variable so that the user can also set it manually e.g. if they don't have the full SuperCollider repository.

Oh, when building against system-installed SC headers? Yeah, that makes sense. It would be even better if we could get the version from the headers but that's not feasible, right?

Finally, the version detection should be part of the SuperCollider3 find module (https://github.com/supercollider/sc3-plugins/blob/main/cmake_modules/FindSuperCollider3.cmake) so that SC_VERSION is set together with SC_PATH.

Yeah, that's fair. And that script could probably be updated to search system directories, right?

EDIT: I realize that we don't bundle the include directory with the release versions of SC on Windows and macOS - I guess we could do that? And search these paths as well here? That way one could build plugins against a release version on these platforms without separately downloading SC source...

[Spacechild1]

We are also currently using here PROJECT_VERSION from SC that we removed after 3.14 -

Just to be clear, the PROJECT_VERSION_<X> variables have not really been removed. It's just that before 3.14 they have been set explicitly, but since 3.14 they are set implicitly via the VERSION argument for the project command:

project(SuperCollider VERSION ${SC_VERSION_MAJOR}.${SC_VERSION_MINOR}.${SC_VERSION_PATCH})

See also https://cmake.org/cmake/help/latest/variable/PROJECT_VERSION.html#variable:PROJECT_VERSION

I tried to address that in #429. Let's move the discussion there on how to handle the relationship of the version of the plugins vs SC.

Great, will do!

It would be even better if we could get the version from the headers but that's not feasible, right?

Theoretically, it's doable: you only need to compile a tiny test program that prints out the version number.

The problem is that the version header common/SC_Version.hpp is not public and it's only created when the SuperCollider project is configured. (The input file is common/SC_Version.hpp.in.)

Having a public version header would be great, though. Currently, SC_Version.hpp is not installed and not part of supercollider-dev packages. But again, that header would only exist if SuperCollider itself is configured/build or installed. You wouldn't be able to use it if you're just cloning the SuperCollider repo.

I think using SCVersion.txt is fine. It's also installed as part of the public headers! See for example: https://packages.debian.org/trixie/amd64/supercollider-dev/filelist

Side note: instead of / in addition to shipping SCVersion.txt, it would be cool if SC would provide a proper CMake module. This would export not only the version number but also an interface library target (SuperCollider::Supercollider) that already contains the necessary include paths, so that plugins can simply do:

find_package(SuperCollider3)

add_library(myPlugin MODULE)

target_link_library(myPlugin PRIVATE SuperCollider3::SuperCollider3)

Yeah, that's fair. And that script could probably be updated to search system directories, right?

Yes, that would be great!

EDIT: I realize that we don't bundle the include directory with the release versions of SC on Windows and macOS - I guess we could do that? And search these paths as well here? That way one could build plugins against a release version on these platforms without separately downloading SC source...

Yes, that would be great! Actually, Pd does this, exactly for this very reason. I have always wondered by SC doesn't do this, I just always forgot to bring it up...

[dyfer]

Just to be clear, the PROJECT_VERSION_<X> variables have not really been removed.

What I meant was that they were removed from SCVersion.txt, so they won't show up after running include("${SC_PATH}/SCVersion.txt") in a 3rd party project, e.g. in sc3-plugins. That's what happens currently when trying to build the current version of the plugins against the develop branch of SC.

I think using SCVersion.txt is fine. It's also installed as part of the public headers!

That's great, I didn't know. BTW who decides what's part of public headers? Do we have a way of ensuring everybody includes SCVersion.txt as part of the headers?

I'll take a look into adding the include folder to SC binaries. BUT again, where do we decide what to include?

[Spacechild1]

What I meant was that they were removed from SCVersion.txt, so they won't show up after running include("${SC_PATH}/SCVersion.txt") in a 3rd party project, e.g. in sc3-plugins.

Ah, I see what you mean now!

That's great, I didn't know. BTW who decides what's part of public headers?

Anything that's in supercollider/include is public, the rest should be considered private. SCVersion.txt is a bit of an exception because it's not really a header file. I would consider it a CMake utility module and therefore install it to <prefix>/share/cmake/SuperCollider.

Do we have a way of ensuring everybody includes SCVersion.txt as part of the headers?

It is installed to <prefix>/include/SuperCollider together with the public headers:

https://github.com/supercollider/supercollider/blob/9433614f6adfbaa37897502ae7b09d32ad5b3e29/CMakeLists.txt#L454-L462

I package maintainer would have to intentionally remove it and there is no good reason for doing so.

[dyfer]

Should I make a PR to use the old extension on Linux based on PROJECT_VERSION_ then? Me and @capital-G were tentatively planning to release sc3-plugins 3.14 this coming weekend so we'd need the plugins to build for the older version of SC properly. Conversely, I don't think we should change version handling (#429) before making that release.

[Spacechild1]

Sounds fine to me!