Update scel submodule #4700
Update scel submodule #4700
Conversation
Also remove HelpSource/Guides/EmacsGUI.schelp since its contents has been
moved to Classes/EmacsBuffer.schelp in scel/HelpSource.
Note that due to a bug in the supercollider CMakeLists.txt file,
Guides/EmacsGUI.schelp was actually never installed if SC_Qt was OFF:
```cmake
if(NOT SC_QT)
set(SCCLASSLIB_EXCLUDE_REGEX "${SCCLASSLIB_EXCLUDE_REGEX}|GUI")
endif()
```
|
thanks @mlang ! have you given any thought to supercollider/scel#10? if we're updating the main repo's submodule, maybe it's a good idea to mark that as a release in scel? |
|
Since scel is a submodule of the main supercollider repo, I dont see any
particular gain in tagging "releases" in the scel repo. In a sense, the
submodule pointer serves already as a tag. It points to the scel revision
which is considered stable from the point of view of the respective
supercollider revision. If we'd tag scel, we should probably
include the hash of the revision of the main repo in the tag name, which
seems a rather weird thing to do.
Lets not treat scel as a standalone repo for now.
There are other reasons why we dont want to do that.
For instance, it would be nice for CMakeLists.txt to be able to reuse
variables defined in the superproject. Like ${auxresourcesdir} for
instance. Treating scel as a potential standalone repo would lead to
needless duplication for no particular gain IMO.
|
|
that seems fine to me -- do however note that for Debian at least, scel is packaged separately as the supercollider-emacs package (https://packages.debian.org/buster/supercollider-emacs). i have no problem with semantically considering whatever is tagged in the main repo at the time of a release to be that "version" of the submodule.
i think it would be totally fine to do that -- IIUC the only reason it isn't is plain code rot. |
|
Brian Heim <notifications@github.com> writes:
that seems fine to me -- do however note that for Debian at least, scel is
packaged separately as the supercollider-emacs package
Yes, but it comes from the same source package.
```console
$ apt-cache show supercollider-emacs|grep Source
Source: supercollider
```
It is a pretty common practice to split the result of
a build into several different binary packages.
So, as I see it, there is no real need to have anything other then
the submodule pointer to keep compatible code in sync and identifiable.
|
|
agreed! |
|
@mlang: Agreed that the Emacs package can share sources with the main supercollider package, but what then of bug fix releases? Unless upstream supercollider can be bothered to spin new releases just for emacs-scel bug fixes, this would still force packagers to use out-of-band, non-releases. My 2 cents! |
|
yes, but coordinating and creating releases is a time consuming and thankless process. with the limited resources we have there's a good argument to be made for keeping it as simple and direct as possible. |
|
OK. Thanks for the feedback, and kudos you for maintaining these programs! |
Also remove HelpSource/Guides/EmacsGUI.schelp since its contents has been
moved to Classes/EmacsBuffer.schelp in scel/HelpSource.
Note that due to a bug in the supercollider CMakeLists.txt file,
Guides/EmacsGUI.schelp was actually never installed if SC_Qt was OFF: