fail on absence of install dependencies

[albfan]

Working on #327 I tweak clink

$ premake5 clink_release

but I had detected a silent build error when some of these program is missing:

• visual studio 2013 (msbuild.exe at least)
• makensis (create installer)
• 7z (zip pdb)
• pandoc (generate docs)

Wouldn't it be useful to point to installer for this dependencies? or return an error when https://github.com/mridgers/clink/blob/master/installer/premake4.lua#L33 fails?

[mridgers]

I put clink_release together for my own benefit really - I was never expecting anyone else to run it. That said, I can definitely do a pass and make it more tolerant and informative.

[vladimir-kotikov]

👍 It would be also great to make pandoc and makensis dependencies optional.

[albfan]

Yes @mridgers , that's what it looks like.

For me seems interesting because I do not know much windows project with a complete build/install toolchain (let alone a command line one). This can be a guide to standarize other projects.

I think that offering a robust install config, can be a source of cool proposals (one that has been long on my mind is to optional deploy a selection of clink-completions during install) I guess @vladimir-kotikov would agree to that.

clink is exponentially useful with that completions, and many ones do not know/care how to install it, and many third parties using clink would benefit from an updateable installer.

I would start a PR/WIP about this. For it's size I guess it would be better to open a branch (develop/review) and squash/merge when work is done. Don't worry if it is finally not merged, but hope you find it useful and do it.

[mridgers]

I've done a pass over this now so that "premake5 clink_release" is much more tolerant of what may or may not be available. It will attempt to fall back to using Mingw if there's no MsBuild in the path, and will skip building an installer or the .zip packages if the required tools are not available. Pandoc is no longer required either which the "clink_doc" action required (see #331). I've been keen to get rid of this dependency for a while as it was a "sledgehammer to crack a nut" really.

As for the remainder of the disucssion regarding the handling of completion scripts, I'll be the first to admit that Clink falls flat here. Just looking in the DLLs location for .lua scripts is not at all ideal. I have been experimenting with this on and off and am and am settling having Clink search the following instead;

1. The DLL's path.
2. A scripts_path setting.
3. Any clink_scipts_path environment variable that maybe set.

The last two can be comma separated paths so that it is easy to specify multiple paths. I'm thinking it would be good to search recursively too (so that one could use git submodules for example).

To further improve user experience and make it easy to add/remove/create/edit scripts I'm thinking along the lines of adding some new commands too. I've not entirely thought it through yet, but something along these lines;

clink scripts addpath <path>
clink scripts removepath <path>
clink scripts create <name>

[mridgers]

Closing as the original issue has been addressed.

[albfan]

All sounds handy. About git submodules, you don't need to go that far.

https://github.com/VundleVim/Vundle.vim

Is an example of a good maintainer of plugins with subdirs and simple unrelated git repos.

consider this besides your suggestions (traversing all added paths):

clink scripts status --> (uptodate, outdated plugins)
clink scripts update -->(update all plugins)
clink scripts update <name> -->(update some plugin)
clink scripts incomming <name> --> (a "git log --oneline" to ensure what changes you will adquire)

To me it sounds better clink plugins than clink scripts but is up to you.