Why not use KDE dependencies ?

[yurivict]

Is there an existing issue for this?

• I have searched the existing issues

Is this feature provided in the master branch?

• I have checked the changelog

The problem you are facing

Why are these git modules used:

[submodule "third_party/extra-cmake-modules"]
	path = third_party/extra-cmake-modules
	url = https://github.com/KDE/extra-cmake-modules.git
[submodule "third_party/syntax-highlighting"]
	path = third_party/syntax-highlighting
	url = https://github.com/KDE/syntax-highlighting.git

?

Why not use packages for these which are part of KDE and are available everywhere?

Describe the feature you'd like

Use external packages when possible.

Describe alternatives you've considered

No response

Are you willing to contribute to this?

• I'm ready to contribute to this (and will open a PR soon)
• I'd like to have a try (with the help of the maintainers)
• No, thanks

Anything else?

No response

[ouuan]

I did suggest that don't include them as submodules (#516 (comment)), but it eventually got merged without this suggestion being resolved (along with some other suggestions, as that PR was stalled too long). Now on Arch Linux (AUR) the system package is used, but not for Windows/AppImage/Deb/macOS.

[ouuan]

Yes, we can fix this now, but I don't think it causes too much trouble for packaging. Maybe some automation script will clone all submodules, causing some waste, but otherwise it should be just fine.

[ouuan]

But I'm not sure whether we should use the system library in AppImage. The version on Ubuntu 20.04 is very old 🤔 (AppImage does not use system library so why not build a new version.) And I'm not familiar with packaging on Deb/macOS, so I think modifications are left to other contributors.

But now I can remove them from the submodules and just clone from upstream in CI.

[yurivict]

They are just unnecessary.

[ouuan]

They are just unnecessary.

Yes, I said that I agree with that.

but I don't think it causes too much trouble for packaging

I mean a new release is not needed to enable packaging with the system library.

[coder3101]

For CI, let's not pull upstream. If we are going system package dependency then let's use whatever stable releases the current OS has to offer.

For macOS, there is a homebrew/tap for linux package managers have this, I am not sure for windows, there's an installer for installing KDE frameworks.

[ouuan]

There are several issues here:

• Putting ECM and KSH in submodules is misleading. It suggests that these versions should always be used instead of the system library. This can be resolved by removing them from the submodules.
• The AppImage. It should bundle the libraries as that's how AppImage works. So let's build the latest version instead of using the very old version on the oldest still-supported Ubuntu LTS.
• The deb package. I'm not sure if we should use the system library. If we do, should we create one deb package for each Ubuntu release? Whatever, we are even not using the system Qt. Our code requires Qt 5.15 which is not available on Ubuntu 20.04. But 20.04 is reaching its EOL, maybe we can switch to the system library after that.
• The macOS package. I don't use macOS so I'm not sure.
• Windows installers. I think Windows applications usually just bundle all DLL files. Or is there a well-known location to install KSH without conflicting with other applications?
• Windows portable packages. By definition, it should bundle the libraries.
• CI. I think the principle is that we use what is used in releases.
• Packages that are not maintained by us. Those are up to the downstream packagers. But yes we should not confuse them like putting ECM and KSH in submodules.

Now I only want to do the removing-from-submodules part. deb and macOS packages (and also CI, accordingly) might be changed in the future.