Right, this is the worst I had feared
the MacOS CI fails now
I don't own a Mac myself so getting that to work will mostly be an iterative process

MacOS CI has been fixed and is being upstreamed mesonbuild/wrapdb#270

Just asking what is the reason to undoing my configurations for subprojects and the utilization of lhelper in the CI ?

I figured since fallbacks are forced on the CI there is no reason to install the packages via lhelper

Please consider that it could be better if the freetype and SDL libraries are not provided as subprojects because they are big and widely available libraries usually installed on systems were people compile things. The Meson subprojects may be better suited to small or not widely used libraries.

Please consider also that by discarding lhelper you may discard quite a lot of work that have been done to fine tune the recipes to build and work correctly and optimally on linux, windows and macos. You may need to redo some of this work like you are already doing without no real improvement for the application itself and the build system wouldn't be simplified either.

Please consider that it could be better if the freetype and SDL libraries are not provided as subprojects because they are big and widely available libraries usually installed on systems were people compile things. The Meson subprojects may be better suited to small or not widely used libraries.

Aren't the subprojects only downloaded if not present on the system?

You may need to redo some of this work like you are already doing without no real improvement for the application itself and the build system wouldn't be simplified either.

I think that the work being done will help us have simpler CI, without us having to depend on lhelper.
It will also help us future-proof, as lhelper recipes are mostly maintained by yourself, while meson wraps have a community that maintains them.
It will also help other projects that use the wraps, as Jan is working on improving them.

Aren't the subprojects only downloaded if not present on the system?

Yes
but in regards to the CI it will always download them because it forces fallbacks

The advantage of subprojects is that they are only downloaded when:

• despite being widely available libraries usually installed on systems were people compile things, they by coincidence turn out not to be installed on that one user's system
• you tell meson "force subprojects because I wanna build a statically linked stack"

And, this happens out of the box. You don't need to know that you must run lhelper first (and you don't need to check which dependencies you have already vs. which ones to run lhelper for). Although if you do run lhelper, meson's existing dependency() calls are functionally unmodified, so it will continue to detect the versions that lhelper installs. :)

It also does not rely on bash scripts (on Windows, which seems to automatically preclude MSVC support), exposes meson's builtin support for lto, pgo, etc.

I am perfectly fine if you remove any reference to lhelper in the CI. I understand the point of @Guldoman that lhelper doesn't have any community behind it. It does even managed to have a community that actively don't want it, which is quite remarkable by itself!

On the other side, if my opinion matters, I would prefer that we do not include SDL and freetype as subprojects.

You may better find some CI solutions to build without lhelper without having SDL and freetype as subprojects.

Probably it would be useful here to have the advice of @adamharrison.

I am perfectly fine if you remove any reference to lhelper in the CI. I understand the point of @Guldoman that lhelper doesn't have any community behind it. It does even managed to have a community that actively don't want it, which is quite remarkable by itself!

I have nothing against lhelper, and I am sure it works perfectly
but the way I see it its a glorified collection of shell scripts and patches to build libraries.

I am sorry, but I personally do not see this as something that a single person (or a handful of people) can maintain til the end of time

On the other side, if my opinion matters, I would prefer that we do not include SDL and freetype as subprojects.

and I would prefer doing it all instead of stopping half way through.

What reason is there not to include SDL and Freetype?
Because they are big and widely available?
Then why use lhelper to build them? just depend on whatever the system has.

not like you have much choice on Wayland since thats explicitly disabled
https://github.com/franko/lhelper-recipes/blob/e9bcbb954387e69748e1b3465d8e6dfa4e29d1c8/sdl2_2.0.8#L43

You may better find some CI solutions to build without lhelper without having SDL and freetype as subprojects.

SDL and freetype are being installed from the OS specific repos

but that is only true when a new release happens

This is why the CI (outside of this PR) creates builds that depend on dynamic libraries.

Nonetheless you obviously do not seem to like this solution so I'm going to close this, someone else can feel free to continue this

I would like to reiterate that from meson's perspective, lhelper counts as a system version and wraps are only used if lhelper did NOT provide them first.

On the other side, if my opinion matters, I would prefer that we do not include SDL and freetype as subprojects.

As a matter of curiosity, under what conditions are you concerned that meson erroring out with "required dependency could not be found" is better than using a subproject?

As a matter of curiosity, under what conditions are you concerned that meson erroring out with "required dependency could not be found" is better than using a subproject?

The user will say: "oh, I need the SDL library to compile this, let me install the needed dev packages before" instead of starting out of nothing to download and build the whole SDL library. Building the SDL library is not something we should do just like this, on the fly. Of course this is a matter of "taste" or "judgement" so people may not agree but I am expressing my point of view.

If you which to implement a smart system for the CI to do a custom build of the SDL library and do a static link it can be done in the CI job itself, without using lhelper if you wish so.

This is tuneable. Meson's --wrap-mode= option takes a range of options:

• default: try to download and build as a last resort
• nofallback: forbid using wraps
• nodownload: only use wraps as a last resort, and only if they've been manually downloaded beforehand
• forcefallback: reject system versions, always use wraps
• nopromote: if a subproject is used, for whatever reason, don't also look in the subproject to detect wraps recursively

For your purposes, the only relevant ones are:

• forcefallback (useful if you want to build all deps from source and maybe build a statically linked installer)
• nodownload (as a matter of taste / judgment, don't use wraps by default, only if the user manually specifies to use them or if the user adds a prebuild step that downloads the subproject sources)

You can set the value to nodownload in the lite-xl project() function via default_options.

The user will say: "oh, I need the SDL library to compile this, let me install the needed dev packages before" instead of starting out of nothing to download and build the whole SDL library. Building the SDL library is not something we should do just like this, on the fly. Of course this is a matter of "taste" or "judgement" so people may not agree but I am expressing my point of view.

I don't think this is a good point.
A normal user doesn't really compile from source, but instead downloads from releases.
If a user really needs to compile from source, the less resistance they find, the better (considering that compiling freetype and SDL doesn't take too much time and that we could just tell them the list of dependencies to install).

For a distro packager, they know better.

If you which to implement a smart system for the CI to do a custom build of the SDL library and do a static link it can be done in the CI job itself, without using lhelper if you wish so.

Right now, are releases done automatically, or do you have to upload them manually?
At least for 2.0.4 I know that some of the packages were uploaded manually, as there are extraneous files inside (in the linux releases there is the terminal plugin).

I don't think this is a good point. A normal user doesn't really compile from source, but instead downloads from releases. If a user really needs to compile from source, the less resistance they find, the better (considering that compiling freetype and SDL doesn't take too much time and that we could just tell them the list of dependencies to install).

I think we have all given our point of view and each of those views is reasonable, it is now mostly a matter of judgement, there are no hard rules to say which option is wrong and which option is right.

I requested the advice of @adamharrison before deciding anything and I didn't close this PR, it was closed by @Jan200101 himself.

A thought we may post a pinned message to say to people to not propose changes in the build system because I am sensitive to this subject and I don't want to change and people have also different ideas themselves (cmake, meson, simple makefile, simple script etc). I am afraid this is a source of frustration for people and a waste of time. We could put our energy and our intelligence into more useful things to improve the application itself.

Right now, are releases done automatically, or do you have to upload them manually? At least for 2.0.4 I know that some of the packages were uploaded manually, as there are extraneous files inside (in the linux releases there is the terminal plugin).

All releases have always been compiled by myself and uploaded manually to github. I have also an Apple certificate I paid for to sign the MacOS packages for notarization.

In the past I had a system in the script to avoid adding extraneous files by accident but it was removed on a request from package maintainers because it required git, so now it can happen by error. I will try to pay more attention in the future.

[…] it was closed by @Jan200101 himself.

I have no interest in fighting to get a change in that one of the main contributors / maintainers reacts defensive about.

A discussion had been held at #768 and I simply acted upon points repeated by many.

A thought we may post a pinned message to say to people to not propose changes in the build system because I am sensitive to this subject and I don't want to change and people have also different ideas themselves (cmake, meson, simple makefile, simple script etc). I am afraid this is a source of frustration for people and a waste of time.

I'm sorry, I don't think I understand what you mean here, could you please clarify?
Is discussing about dependency management, build systems and improving CI really a waste of time?
As far I can see, discussion about this was going mostly frustration-free.

All releases have always been compiled by myself and uploaded manually to github. I have also an Apple certificate I paid for to sign the MacOS packages for notarization.

In the past I had a system in the script to avoid adding extraneous files by accident but it was removed on a request from package maintainers because it required git, so now it can happen by error. I will try to pay more attention in the future.

I don't think it's a good idea having to rely on human factors to create releases, we should really get the CI for the releases up and running.
I understand that this might be difficult to do for macOS releases as they have to be signed, but for the other releases we should automate it.

Also about macOS releases, could you give a look at #687?

I'm sorry, I don't think I understand what you mean here, could you please clarify?
Is discussing about dependency management, build systems and improving CI really a waste of time?

Discussing about changing the build system and the dependencies, yes, because I would probably refuse to change.

Improvements and changes in the CI on the other side are welcome and as I said lhelper can be removed if we found out better.

As far I can see, discussion about this was going mostly frustration-free.

I am sorry about that, I didn't want to frustate people but I have the right to say my word about the project.

I don't think it's a good idea having to rely on human factors to create releases, we should really get the CI for the releases up and running.

Maybe. The human factor is small because I use some build scripts and these can be improved. Only the Macos script is kept private because I wasn't able to separate it from the sensitive data but it does use the build-package.sh script.

I understand that this might be difficult to do for macOS releases as they have to be signed, but for the other releases we should automate it.

I'm fine to automate the creation of the released packages.

As for the Macos package problem, I got it, I will fix this for the 2.0.5 release, thank you.

Improvements and changes in the CI on the other side are welcome and as I said lhelper can be removed if we found out better.

lhelper
is not used
for CI

I would like to reiterate once again:

• not only does lhelper get first dibs at satisfying the dependency (if you choose to run lhelper)
• meson can be instructed to not use wraps by on the fly unless specifically opted into, if this project prefers that behavior.

This, this PR can be purely additive and refrain from changing any workflows for any user or developer, except for when people invoke meson setup with opt-in flags.

Why is adding an ini file which is configured to be ignored by default, such a bad thing? Why is it not a bad thing, as long as it's called "lua"?

Hi all,

I realize I'm late to this discussion. I don't really have a huge opinion on this (I just like makefiles/simple build scripts); and I don't have deep knowledge of meson (and I don't bother using it), so I'm not best placed to comment.

I think that it can be awkward when it becomes personal like this; so what I'd propose is we simply focus on the realm of what would at least somewhat satisfy all parties, from a feature perspective.

So, @franko , if you don't want to change the build system, could we accommodate these changes in an opt-in manner as @eli-schwartz says? That way, the CI tools can use it as normal, but it doesn't affect your workflow? Would that be acceptable? I know this is a sensitive subject, but I don't think that means that we can't discuss it. Fundamentally, you have the final say on what to include/exclude from the project; but I think part of the point of having a public repository where you accept PRs is that you do entertain these types of discussions.

Likewise, @Jan200101 and @Guldoman, I understand your frustrations here. I do concur that it makes sense to have the CI for releases up and running, and that I don't think the discussion was particularly unproductive.

As a first step, I'd recommend making it opt-in for now to use the fallbacks, and we simply table the topic of the default inclusion of lhelper for a later date (if ever).

Does that work for everyone?

Thank you @adamharrison for your comment, that's useful for the discussion.

So there is a proposition to enable the wraps but for them to be opt-in. I give my consent to go this way even if I preferred to keep sdl and freeetype as external dependencies.

So please continue with this PR.

So Jan has signalled to me this is done; this looks fine to me. Fallbacks are now optional, but we have them specified for each project. Looks good. Merging.