It has nothing to do with your ~/bin symlinks.

In this case, the warning means exactly what it says and has no other ramifications.

The location of the user support directory changed a couple of versions ago. If you want to keep extensions, you'll need to move them, or edit the language configuration (IDE preferences).

Quarks used to use symbolic links for installation. Now it doesn't. So indeed, any quarks you had previously installed (using the old symlink system) need to be reinstalled using the new language-config system.

Nothing more than that.

Thanks for the reply, and apologies - my Markdown was malformed, so you probably weren't seeing the first line of the error:

WARNING: Deprecated support directory detected: /home/adam/share/SuperCollider

I've fixed it now [EDIT: the malformed Markdown, not the original issue]. Anyway, the point I was trying to make is that with my approach of installing into my home directory via Stow, my ~/share/SuperCollider/ contains crucial components of the normal SC install, such as the whole SCClassLibrary/ hierarchy. So this issue is not about where to put personal extensions, or anything to do with installing Quarks (which BTW all work fine), but rather it's about where the core components live.

Bearing that in mind, do you think this warning still makes sense, or is it a false alarm? I haven't noticed anything breaking, but that could be because most of the time I have an SC rpm concurrently installed which places near-identical files into /usr/share.

You can use the language configuration file (IDE > Preferences > Language) to load any directories you want during library compilation, and also suppress the default library locations.

It's no problem to have the library in a nonstandard location -- I do it myself. But it's on the user to configure it -- it won't come that way out of the box.

Hm, maybe this could be clearer. 4 directories are involved, and it's easy to confuse them.

1. Class library location. By default, this is in a system-wide location, but you can change that using the library configuration file (Preferences > Interpreter [not Language, my mistake]). You happen to have put your class library into the user support directory, but it's still a totally separate concept from the user support directory. The "Deprecated support directory" message has nothing to do with the class library, period.

2. User support directory. This is fixed:

   Platform.userAppSupportDir;
   -> /home/dlm/.local/share/SuperCollider
   

   It's set internally, in C++, and you can't change it. The "Deprecated support directory" is referring to this location. In Linux, it used to be in a visible location (I forget where). A couple of years ago, it changed to ~/.local/share/SuperCollider to conform with the UNIX Filesystem Hierarchy Standard (FHS). FWIW, I prefer to have my support directory in a visible place. So I deleted the directory and did ln -s ~/.local/share/SuperCollider ~/share/SC and... no problem. SC finds app support files where it expects (via symlink), and I don't have to expose hidden files to go there in the file browser.

3. Extension directory -- Platform.userExtensionDir. This is also set by a primitive, to be within the user support directory. BUT you can add more extension directories using language configuration.

4. Quarks installation.

   • Old way: Quarks are downloaded into [user support]/quarks. Installing them created a symlink under [user support]/Extensions/quarks.
   • New way: Quarks are downloaded into [user support]/downloaded-quarks. Installing them adds the downloaded-quarks/[quark_dir] directory into the language configuration -- no symlink.

   "Quarks will need to be reinstalled due to broken symbolic links" is referring to the "old way" quark installations. This message doesn't know or care about any symlinks you created for STOW.

Does that make it clearer? It's a lot of locations with different meanings... not immediately apparent.

@aspiers Do you consider this resolved? I'm not sure what's actionable in this issue.

No, it's not resolved.

@jamshark70 Thanks a lot for the info - actually I already knew a lot of that, but it was very useful to have the full story (including historical details) in one place! However this still doesn't really explain how to resolve the problem.

As you say, I happen to have installed my class library into the deprecated location for the user support directory, but SuperCollider's deprecation test does nothing more than a basic

if (sc_DirectoryExists(deprecatedSupportDirectory)) {

test, so it can't tell the difference. Therefore I get this error, even though ~/share/SuperCollider is the most logical location for the class library in a non-root home-directory installation.

AFAICS the warning is spurious and nothing breaks with me installing things this way. Or am I missing something?

Of course one obvious workaround is to install the class library elsewhere, but it'd be nicer to fix the issue. For example, I notice that it is expected that userAppSupportDir contains a Help subdirectory, whereas the class library doesn't. So could it be fixed simply by adding a check for the presence of that subdirectory?

For example, I notice that it is expected that userAppSupportDir contains a Help subdirectory, whereas the class library doesn't.

Hm, maybe not that one specifically. [appsupport]/Help is created the first time you access the help system, not before.

If I launch SC with an empty app support directory, I get these:

downloaded-quarks
HistoryLogs
synthdefs

But they are created in class library code -- that is, the sequence is a/ sclang init; b/ compile library; c/ run startup activities. These directories are created in c/, but the "deprecated support directory" warning is posted in a/. So, even if you check for one of these subdirectories, you would still get the warning the first time you start sclang (but maybe not thereafter). It's a "most of the time" approach, not a technically solid "every time" approach.

TBH I think the best solution is to use a different directory name. If it's a case-sensitive filesystem, why not ~/share/supercollider? It's very common for software names to be capitalized in print but all lowercase in filenames. (In fact, I already have ~/share/supercollider -- it's my git clone of the SC sources -- so I can say for sure, SC doesn't complain about that as a deprecated directory.) Or ~/share/SC?

I'm not trying to be stubborn... but we're talking about changing it for everybody, to suit one user's preference. I know it's annoying, but I don't think the pain level is that high. With 530 open issues, I'd be willing to bet there are at least 10 or 20 that need more immediate attention than this -- so, a change here isn't cost-free if it diverts developer time. (You could reduce the cost by implementing a fix and sending a PR -- i.e. you could spend 20 seconds to change a directory name, or a longer time on a code fix, or ask somebody else to take time away from something else to do the code fix for you.)

Or, perhaps a better thought: If we consider making user app support and extension directories configurable rather than hard-coded, then you have an enhancement request that could benefit many, many users, rather than a workaround for one user's issue. Many users (including myself) didn't like it when the app support directory moved to a hidden location (even though the technical reason was sound).

I'd be in favor of discussing a broader ER, which could potentially include a "deprecatedSupportDirWarning" flag in the language config file.

@jamshark70 Thanks for the many great comments and I agree with a lot of what you've written :-) Certainly this is far from being the most important SC issue out there, and I could probably take care of submitting any fix as a PR once we've decided the best way forwards (assuming the fix is relatively simple).

However I do want to note that I did not choose this exact path ~/share/SuperCollider myself - it was simply the result of doing a non-root compile from git and install into my home directory. True, I chose to add the extra layer of indirection via GNU Stow, but I'm pretty sure anyone who does

cmake -DCMAKE_INSTALL_PREFIX=$HOME
make install

will experience the same (on Linux at least). So you say that I could "choose" a different directory name, but this would require me to learn the basics of cmake and wade through a bunch of makefile stuff, which would probably take me longer to figure out how to do than simply improving the logic of the deprecated warning code. Or maybe you can suggest some magic cmake incantation which allows me to specific the location of the installed class library?

SWIFT UPDATE: OK, I guess cmake is similar enough to make and all the other UNIX-y things I already know that I managed to find these:

CMakeLists.txt:133:	add_definitions(-DSC_DATA_DIR="${CMAKE_INSTALL_PREFIX}/share/SuperCollider")
editors/scel/el/CMakeLists.txt:7:set(PKG_DATA_DIR ${CMAKE_INSTALL_PREFIX}/share/SuperCollider)

and in fact there are many more mentions of /share/SuperCollider found via git grep. But it sure looks like these are all hardcoded paths rather than parametrized, which backs up my previous estimate that it would be way harder to change the installation path of the class library than to fix the deprecation warning. I'm inclined to suggest that the lack of parametrization here is actually a bug with the installation process. Most other makefile-based software packages allow you to tweak top-level install destination directories simply by modifying a parameter either at the ./configure / cmake stage, or post-compile during make install.

However I do want to note that I did not choose this exact path ~/share/SuperCollider myself - it was simply the result of doing a non-root compile from git and install into my home directory. True, I chose to add the extra layer of indirection via GNU Stow, but I'm pretty sure anyone who does

cmake -DCMAKE_INSTALL_PREFIX=$HOME
make install

will experience the same (on Linux at least).

OK, that is an excellent point: if our build system has a nontrivial chance of installing critical files into a location that's also flagged for a warning, then it's reasonable to fix the build system.

Or maybe just remove the warning. It's been 6.5 years. According to https://github.com/supercollider/supercollider/releases?after=Version-3.5.3, in 2011 we were on 3.3 or 3.4. It's increasingly unlikely that anyone still needs to upgrade from one of those versions.

Thanks for pointing that out. Although it's a nonstandard installation strategy, I'm convinced by an inconsistency between the build system and sclang's behavior.

Glad we're on the same page. As per the hardcoding mentioned above, I suspect it would take way more effort to fix the build system than to remove the 6.5-year-old warning :-)