dundargoc

@justinmk I believe this PR to be stuck without your input as people seem to have different interpretations on what the purpose and scale of the guide should be.

> I think it would be really good to note there that plugins that don't require LuaJIT should use Lua 5.1 syntax. So e.g. don't use goto's, .. I think...

> Build should not break unexpectedly because GitHub changed their tarball generation strategy in the future. Meh. From end user perspective this is a non-issue. Github changes tarball strategy ->...

> If on the other hand you download a tarball from e.g. https://github.com/libuv/libuv/archive/541329d51f82bce83bd81ff7640edabfc32d149c.tar.gz, you lose the entire security benefit of checking the hashes in case e.g. the user sits behind...

@thestr4ng3r for clarification, do the tarballs from manual releases not have the problem you described with the automatically generated tarballs?

I checked: most of our dependencies do not have their source code manually updated. I think this is a wontfix for the time being, this feels like a systematic problem...

This is basically impossible without nasty hacks. An attempt of this was made in https://github.com/neovim/neovim/pull/22054 and the problem is that `FetchContent` only works with projects who use cmake and we...

> This can probably be worked around by predicting the exact paths of installed files by the external project and putting dependencies on the target created by ExternalProject_Add instead of...

> Or, since they are already being built with a custom injected CMakeLists.txt, would it be reasonable to only integrate those into the main cmake somehow? I'll need to think...

I still don't understand why packaging the parsers are not an option. Is it too much work to package the parsers or what's the problem?