cmake/apple: compile targets directly into the app bundle

[timblechmann]

less code & more robust

[bagong]

The "fix win32 code path seems not to have made it into master. It is required to build on Windows.

[danstowell]

A Mac user needs to decide if the significant Apple change here can be merged. If the win32 fix is a separate topic, it should be a separate PR, sorry. Feel free to post that as a separate PR, it should be harmless to do that.

[timblechmann]

@danstowell it can and should be merged. while i'm not using sc on osx, i did compile it.

[danstowell]

@timblechmann thanks. I think the change looks good, but I really would prefer if one of the mac-using maintainers could be the one to sign this one off, i.e. check it.

[timblechmann]

@danstowell, by running a clean build, one won't see a difference. fwiw, instead of testing it would be much better, if someone could review the change. though this would need some effort to try to read the code, understand what is going on, maybe by looking even up the cmake documentation.

[danstowell]

@timblechmann not sure why you're telling me that. I have indeed reviewed it by reading the code and understanding it, though at this point I want a mac-using maintainer to check it too, since they have more invested in the outcome than I do!

[bagong]

fwiw, the files land where they're supposed to be (I actually tried it :)). And you do see a difference if you build supernova - which not many proper mac-maintainers do. So this might stay in a pending state for a while if we are realistic...

So do I need to make a separate pull request for the Win line?

[bagong]

The HelpSource Folder is created twice: once inside the toplevel SuperCollider folder (alongside examples) and once inside the app-bundle.

[bagong]

If on OSX you build with scel support the scel related files are written to a folder "share" in parallel to the SuperCollider folder

[timblechmann]

just in case someone runs into broken builds, someone might want to merge this PR

[muellmusik]

If on OSX you build with scel support the scel related files are written to a folder "share" in parallel to the SuperCollider folder

@bagong IIUC, that's correct, so I've merged this now. If I've missed something can you open a new issue.

[scztt]

Where does this leave an OSX user building standalone sclang / server?

[bagong]

The build option "standalone" is completely broken. What we currently get are the remnants of an old way to create a completely self-contained sc-bundle that could even be sort of "branded". This worked until 3.4, if I am not mistaken. There used to be a default folder in the source tree in which one was supposed to copy custom-classes which would be added to the class-library during build. This whole mechanism went away with the new IDE.
In theory though it should still be possible to rename the application bundle via the cmake-option and have the resulting sc-variant write to a userAppSupportDir with that bundle name. That wouldn't be an isolated standalone, but it would allow different sc-installs to coexist peacefully. Unfortunately only a small part of the sc-managed user-config/extension-files (to be exact only the ones controlled by the IDE itself: startup.scd, sessions-folder, and the config.yaml-files) honor a bundle-name redefined via build option. All other files (help, extensions, quarks, history...) continue to write to/look into the default folder SuperCollider in the general appSupportDir - so different installs will write help-files to the same location, you cannot separate extensions etc...
Platform.userAppSupportDir returns ..../SuperCollider regardless of the defined bundle name, and that is apparently what is used by most.

More or less independent from this Miguel added a startoption to sclang that in conjunction with config.yaml-files allows to limit the folders sclang looks into, to the ones in the config.yaml. This works nicely, but it is not integrated into the IDE.

[scztt]

Yeah, I ask because in my day-to-day workflow I use standalone builds of sclang, custom config.yamls, and non-default SCClassLib's / support dirs, and I plan on sharing tools to handle some of the scenarios you described (i.e. standalone, co-existence, etc) when they stabilize a little. Now that we've stuck the whole damn thing in the IDE app package (which I thought was a great idea years ago when it was done....), I've changed my mind and am of the opinion that sclang/server/SCClassLib should absolutely NOT be there. :)

[bagong]

Does the IDE provide a way to start a sclang binary outside of the bundle and add arguments? That could be a nice step towards decoupling IDE and sc-proper. Not sure about the side-effects though.
Balancing ease of install, cli-less-use and flexibility, as well as maintaining cross-platform compatibility creates a complex issue. The quarks discussion in the dev-list, as well as the question which missing classes sclang should complain about if used outside the IDE, seem to belong here as well.
I like the Atom-editor principle of "one project one folder" a lot. Feels like a gordian knot to all these - sort of related - questions. I think you'd get a lot of sympathy (not necessarily help :)) if you'd raise your points on the dev-list.

[muellmusik]

Now that we've stuck the whole damn thing in the IDE app package (which I thought was a great idea years ago when it was done....), I've changed my mind and am of the opinion that sclang/server/SCClassLib should absolutely NOT be there. :)

@scztt can you say a little about why? I can understand in a headless config you might want that, but I kind of like the convenience generally.

[scztt]

@bagong The IDE does have a way of specifying an sclang binary, although it's just a text field and you can't also, e.g., specify the SCClassLibrary, so it's not really a complete workflow.

@muellmusik I didn't mean to overstate - I think you should be able to download a single SuperCollider app and have it just work. I think there probably SHOULD be a copy their for convenience sake, but in general the IDE should be LESS wedded to a specific (internal) classlib, not more. I have ~8 years of SuperCollider projects / odds-and-ends at this point, plus lots of things in that time that I've contributed to / collaborated on that rear their heads occasionally. Many of the things from the past few years need to co-exist on my machine at any given time (i.e. now), and each brings with it dependencies on a version of the classlib, quarks, and personal quarklets/class files. So I'm currently stuck with multiple copies of the SCClassLib (and corresponding sclangs, since they're basically version locked), and at least three copies of the IDE (live 3.7, 3.6.x, and Cocoa). Though a more casual user won't necessarily have the same extended history, EVERYONE has code from X years ago, made with an unknown version of SC with unknown Quarks installed, that probably wouldn't run if they tried it right now (and, the casual user is much LESS equipped to track and deal with subtle code failures due to missing quarks / classlib version diffs / etc).

In an ideal world (well, MY ideal world... :) ), I could store the requirements for a SC project, or snapshot an assembled classlib+extensions+sclang (both common features in all modern scripting languages), so that when I need to perform that piece (or just mess around with it again) in a year, at worst I've just got to wait for SC to download a few old Quark versions I no longer have cached. If you've used node.js/npm or ruby gems... basically, that.

I should say - I use a hacked-together version of this workflow now. For code I intend to keep, I'm storing an sclang_conf.yaml alongside that specifies include dirs for the quarks/extensions and classlib version that's required. When I'm working on that project, I can just load that .yaml file in the IDE (this is a local hack - you can't really do this now). I'm midway through making Quarks install directly to the current sclang_conf.yaml instead of the regular directory-linking nonsense, which will smooth things out some more. All that's ugly, but solves some of my problems - I'd love to see the same workflow become easy and elegant, because I think it opens the door to spending more time working in / enjoying SuperCollider, and less time spend worrying about code breakage, or why my old synth doesn't seem to work like it did when I made it in 3.5.

[bagong]

The IDE does have a way of specifying an sclang binary...

@scztt Where would that be? (the only vaguely related field I see is the somewhat mysterious "Runtime Directory" in prefs/Interpreter, but I have not found how that would allow to address sclang)

[scztt]

The Runtime Directory setting allows you to pick an sclang by pointing to the folder that contains it. It's disabled/broken on mac - it's easy enough to just enable it (I'm doing that locally), but it still doesn't really provide a full/usable workflow until some more work is done.
(Meaning even when it works, you're still stuck navigating manually through the filesystem to find a folder with an sclang + classlib, and then restarting the lang, each time you want to change. And - reverting to the default app-embedded one becomes a problem too.)