Description
not making a discussion out of this becasue no one looks at those
since its start lite-xl made use of meson, which sets it apart from lite where building was done via a very basic shell script, though over time meson has been more and more difficult to work with in regards to both the tool itself as well as the project leaving many contributions that fix issues this we would need fixed unresolved.
Some time ago I already proposed switching to cmake however that was mostly shut down, its been quite a while since that and I want to reopen that discussion, especially now that SDL3 is seeing adoption in distos and us wanting to support SDL3 sooner than later due to the many additions that improve user and system interactions.
Lite-XL currently makes use of meson's subproject feature to pull in missing dependencies or even pull them in if distro packages are badly behaved, in the past this has been noted as an important functionality that I'm going to mention later on.
Here are some common options as well as some pros and cons:
+ battle hardened over multiple decades
+ works on every remotely *nix like system
- no official support for MSVC
- relies on lesser known m4 scripting language
- requires 5 different programs to generate a build solution
- cannot pull in or build dependencies on its own+ widely used industry standard
+ officially supports too many build configurations to count
+ completely backwards compatible with older versions of itself
+ single compiled executable
+ can pull in and build dependencies directly with direct integration if they use cmake
- scripting language is a bit obtuse
- no automatic pkg-config integration- still in active development
+ supports any architecture LLVM supports
- no existing tooling for any non mainstream system
+ can pull in and build any dependency written in C directly
- build system is bundled into a toolchain
+ toolchain can build entire project and all dependencies at once- Makefiles
+ single compiled executable
+ a powerful scripting system
- extra work needs to be put in to support unique systems
- not portable
- no dependency management
- unable to pull in or build dependencies on its own- Shell script
+ able to run on all most *nix machines
- hard to make portable
- does not work well for windows
- no dependency management
- unable to pull in or build dependencies on its own
- no concept of build fragments+ able to run on all most *nix machines and Windows
+ build language is literally just python
- not widely used
- requires python as runtime dependency
- can pull in but not easily build dependencies
- requires lots of boilerplate to get fully a featured build script + fair share of adoption
+ can pull in and build dependencies
+ available package repository for dependencies
- unintuitive build logic
- requires JVM as runtime dependencyI feel the need to add that this is not a proposal for a full switch, a system that fits the needs of the project and is capable of fill the hole meson currently occupies should be found and then tried out before meson is removed. If it ends up working as intended then meson support can either be brought along or deprecated.
I'm happy with any of these and I hope we can finally come to a conclusion with this that benefits the project as a whole and not just the bikeshed.