Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

provide scvim system-wide #39

Open
2 of 5 tasks
dvzrv opened this issue Dec 7, 2017 · 7 comments
Open
2 of 5 tasks

provide scvim system-wide #39

dvzrv opened this issue Dec 7, 2017 · 7 comments

Comments

@dvzrv
Copy link
Member

dvzrv commented Dec 7, 2017

On Linux, package managers take care of where files are installed for which application (package) on a system-wide level.
Vim supports several plugin folders, that are tested, when it starts. One is system-wide (all users of a given system can use that plugin) and one is user-specific (only the user starting vim can use that plugin).

As I'm now maintaining supercollider for Arch Linux, I'd like to have a look into how to ship scvim as a plugin package (e.g. vim-scvim or vim-supercollider).
This has the above mentioned benefit of several users being able to use the same installation.
Starting from 3.9, scvim will most likely not be compiled by default (which has the benefit of being able to update scvim, while supercollider is not updated).
Also, to circumvent #27, I have disabled scvim in the updated build of 3.8.0 for Arch Linux.

For this to happen, several things (ideally) will have to be done though:

  • start to version (tag) scvim
  • install supercollider and scvim files system wide
  • install binaries and link libraries (sc_dispatcher and start_pipe)
  • extend initClass and startUp.add of SCVim.sc for a global install
  • bake a package
@capocasa
Copy link
Member

capocasa commented Dec 7, 2017

I am elated! Arch is my favorite distribution.

I have decided assuming the absence of objections that the current state of scvim is now released as v1.0.0, and that we will be using semantic versioning for all future releases.

@dvzrv
Copy link
Member Author

dvzrv commented Dec 7, 2017

@carlocapocasa great to hear!
supercollider-3.8.0-3 without cwiid dependency and without scvim just hit [community-testing]. Feel free to give some feedback!

@mossheim
Copy link
Contributor

mossheim commented Dec 7, 2017

Great, thank you for this!

@dvzrv
Copy link
Member Author

dvzrv commented Dec 30, 2017

Installation destinations for SuperCollider and vim plugin files are pretty easy:

# vim files
install -Dm644 ftplugin/supercollider.vim "${pkgdir}/usr/share/vim/vimfiles/ftplugin/supercollider.vim"
install -Dm644 indent/sc_indent.vim "${pkgdir}/usr/share/vim/vimfiles/indent/supercollider.vim"
install -Dm644 plugin/supercollider.vim "${pkgdir}/usr/share/vim/vimfiles/plugin/supercollider.vim"
install -Dm644 syntax/supercollider.vim "${pkgdir}/usr/share/vim/vimfiles/syntax/supercollider.vim"

# supercollider class
install -Dm644 sc/SCVim.sc "${pkgdir}/usr/share/SuperCollider/Extensions/scvim/SCVim.sc"

# documentation
install -Dm644 README.md "${pkgdir}/usr/share/doc/${pkgname}/README.md"

I noticed however, that the libraries for sc_dispatcher and start_pipe are hard linked. That has to be patched.

Also, SCVim.sc has to be extended to somehow take care of the dynamic loading of Class names.
I'm not yet sure, how that can be achieved nicely.

@dvzrv
Copy link
Member Author

dvzrv commented Dec 30, 2017

Also, I think indent/sc_indent.vim should be renamed to indent/supercollider.vim and syntax/supercollider_operators.vim be merged into syntax/supercollider.vim.

@dvzrv
Copy link
Member Author

dvzrv commented Dec 30, 2017

As for the ruby library destinations, I'm thinking of a location such as "${pkgdir}/usr/lib/${pkgname}/ruby/".
This just has to be patched in the first few lines of the scripts.

@capocasa
Copy link
Member

capocasa commented Nov 7, 2019

Okay let's get this licked, arch needs an scvim package.

I believe @claudiocabral is working on replacing the hardcoded .vim path in SCvim.sc with a search of the actual vim runtime paths in order to support neovim, but should help this as well.

As for the hardcoded path in the ruby files, those load relative to the directory the file is in- can you help me understand how that is a problem for packaging? Don't you just keep the directory structure and all is well?

Do you consider the rename and merge need-to-have or nice-to-have? I'd suggest to just accept the file names are warts unless there is a really compelling reason to change them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants