8000 Why not use KDE dependencies ? · Issue #1322 · cpeditor/cpeditor · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Why not use KDE dependencies ? #1322

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
3 of 5 tasks
yurivict opened this issue Feb 18, 2024 · 7 comments
Open
3 of 5 tasks

Why not use KDE dependencies ? #1322

yurivict opened this issue Feb 18, 2024 · 7 comments
Labels
enhancement New feature or request high_priority High Priority Issues are marked with this label.

Comments

@yurivict
Copy link

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
@yurivict yurivict added the enhancement New feature or request label Feb 18, 2024
@yurivict yurivict changed the title Why not use KDE dependencies Why not use KDE dependencies ? Feb 18, 2024
@ouuan
Copy link
Member
ouuan commented Feb 18, 2024 •
edited
Loading

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
Copy link
Member
ouuan commented Feb 18, 2024

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
Copy link
Member
ouuan commented Feb 18, 2024 •
edited
Loading

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
Copy link
Author

They are just unnecessary.

@ouuan
Copy link
Member
ouuan commented Feb 18, 2024

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
Copy link
Member

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
Copy link
Member
ouuan commented Feb 18, 2024 •
edited
Loading

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.

@ouuan ouuan mentioned this issue Feb 18, 2024
Merged
@ouuan ouuan added the high_priority High Priority Issues are marked with this label. label Mar 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request high_priority High Priority Issues are marked with this label.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@yurivict @coder3101 @ouuan
0