Meson build support of all dependencies

[jgmdev]

I was planning on adding this plugin as part of the build system of Pragtical (as requested by some users), but first needed an easy way to build everything for easy testing and distribution. As title already says this PR adds meson support for easy building and installation of all the required libraries.

Example:

meson setup build
meson compile -C build
DESTDIR=/home/user/.config/pragtical meson install -C build

The above commands will compile all supported tree-sitter parsers and install everything in the following structure:

.config/pragtical
├── plugins
│   └── evergreen
│       ├── config.lua
│       ├── highlights.lua
│       ├── init.lua
│       ├── installer.lua
│       ├── languages.lua
│       ├── LICENSE
│       ├── parser.lua
│       ├── queries
│       │   ├── c
│       │   │   └── highlights.scm
│       │   ├── cpp
│       │   │   └── highlights.scm
│       │   ├── d
│       │   │   └── highlights.scm
│       │   ├── diff
│       │   │   └── highlights.scm
│       │   ├── go
│       │   │   └── highlights.scm
│       │   ├── gomod
│       │   │   └── highlights.scm
│       │   ├── javascript
│       │   │   └── highlights.scm
│       │   ├── julia
│       │   │   └── highlights.scm
│       │   ├── lua
│       │   │   └── highlights.scm
│       │   ├── rust
│       │   │   └── highlights.scm
│       │   └── zig
│       │       └── highlights.scm
│       ├── README.md
│       ├── style.lua
│       └── util.lua
└── tree-sitter
    ├── ltreesitter.so
    └── parsers
        ├── libtree-sitter-cpp.so
        ├── libtree-sitter-c.so
        ├── libtree-sitter-diff.so
        ├── libtree-sitter-d.so
        ├── libtree-sitter-go-mod.so
        ├── libtree-sitter-go.so
        ├── libtree-sitter-javascript.so
        ├── libtree-sitter-julia.so
        ├── libtree-sitter-lua.so
        ├── libtree-sitter-rust.so
        └── libtree-sitter-zig.so

Compiling for Distribution

For easy distribution, static compilation is supported since subprojects are provided for all the base required libraries. The compilation procedure would be the same as above with the only difference of forcing all fallbacks:

meson setup --wrap-mode=forcefallback build
meson compile -C build

These PR doesn't provides the CI building bits, that should be worked separately.

Build Options

The following build options are provided for controlling the lua runtime to use:

option('use_system_lua', type : 'boolean', value : true, description: 'Prefer System Lua over the meson wrap')
option('jit', type : 'boolean', value : true, description: 'Use luajit')

These options can be used at setup time as follows:

meson setup -Duse_system_lua=false -Djit=false build

[TorchedSammy]

what the hell

[TorchedSammy]

is the 900k+ file really needed in this pr? i'm very much hesitant to merge this at all, considering meson isn't generally useful and it's only for pragtical.

[jgmdev]

is the 900k+ file really needed in this pr?

The tree-sitter-d repository isn't sadly distributing the generated parser code and since I didn't wanted to kick a rust build of the tree-sitter cli app just to generate the D parser code on the fly I opted to include the generated parser, maybe the repository owner could be contacted to generate one for us (git should compress the file so shouldn't be an issue).

i'm very much hesitant to merge this at all, considering meson isn't generally useful and it's only for pragtical.

The idea of this PR came while I was playing on my macbook air yesterday since I couldn't test this plugin. It is to allow easy building of all needed libraries in order to later add a github workflow for automated builds and adding a plugins manifest.json for easy user installation using lpm/ppm. This way it would be less of a hassle trying to get the plugin working on different operating systems or architectures.

[TorchedSammy]

The tree-sitter-d repository isn't sadly distributing the generated parser code and since I didn't wanted to kick a rust build of the tree-sitter cli app just to generate the D parser code on the fly I opted to include the generated parser, maybe the repository owner could be contacted to generate one for us (git should compress the file so shouldn't be an issue).

i don't like having to include it at all. maybe you should tell something to who's working on the d parser, or just use the cli since that's what it is for?

adding a plugins manifest.json for easy user installation using lpm/ppm

a manifest.json is separate from needing meson?

It is to allow easy building of all needed libraries

this part i don't get since evergreen will build the treesitter parser if it can't download from the external builds repository. i think your problem was that ltreesitter is only built for x86_64 and therefore wouldn't work on a mac, and evergreen does not compile ltreesitter locally. if evergreen does not compile the parser for any reason, that is a bug that should instead be reported.

additionally, changes in #54 make it so that users can define all parsers via lua config and whether they want to grab the precompiled bins or compile locally, which i think fixes this issue in a better way.

also, i don't use meson. i'm not interested in updating this whenever i need to add a new parser, sorry.

in any case, supporting more systems than current is a good thing! i don't like this method of doing it. i would rather even just include a submodule of ltreesitter and users can build like that. the great thing is that 99% of the time the submodule wouldn't have to be grabbed.

[jgmdev]

i don't like having to include it at all. maybe you should tell something to who's working on the d parser, or just use the cli since that's what it is for?

One way would be to detect if tree-sitter cli app is installed and use that to generate the parser on the fly, and if not just skip building the language. Also meson supports building rust projects, so building the cli application from the tree-sitter subproject and using the resulting binary to generate the parser is a possibility, but will need to investigate how to properly do it.

a manifest.json is separate from needing meson?

I didn't worked on that too because working on the github workflows is time consuming and was feeling tired. But the idea is that each tree-sitter-lang can be defined on the manifest.json as a plugin that can be optionally installed, which would reduce the amount of code needed on evergreen to handle parsers installation, or just complement the way a user can install additional parsers.

this part i don't get since evergreen will build the treesitter parser if it can't download from the external builds repository. i think your problem was that ltreesitter is only built for x86_64 and therefore wouldn't work on a mac, and evergreen does not compile ltreesitter locally. if evergreen does not compile the parser for any reason, that is a bug that should instead be reported.

The plugin just downloaded the shared library compiled for linux which would obviously fail to work. So my problem was I couldn't easily test the plugin on another OS without having to manually clone, compile and install many stuff manually which this PR does for me in 3 commands. Also I mostly prefer building the plugin and parsers locally.

additionally, changes in https://github.com/TorchedSammy/Evergreen.lxl/pull/54 make it so that users can define all parsers via lua config and whether they want to grab the precompiled bins or compile locally, which i think fixes this issue in a better way.

Didn't saw that one, that is a good direction!

also, i don't use meson. i'm not interested in updating this whenever i need to add a new parser, sorry.

in any case, supporting more systems than current is a good thing! i don't like this method of doing it. i would rather even just include a submodule of ltreesitter and users can build like that. the great thing is that 99% of the time the submodule wouldn't have to be grabbed.

Maybe since you are unfamiliar with meson you think that way, happens the same to me with other technologies, but I try to adapt. Anyways, closing this PR since it isn't of interest.

[TorchedSammy]

there can be a discussion about having ltreesitter work for other systems in a separate issue tho. i guess just try to compile if it's not available to download?