Add build-flatpak target if there is a flatpak recipe around
AbandonedPublic

Authored by elvisangelaccio on Aug 11 2017, 4:23 PM.

Details

Reviewers
apol
Group Reviewers
Frameworks
Summary

If there is a org.kde.*.json file in the git repository of the cmake
project, we assume is a flatpak recipe and we add an optional target
that runs flatpak-builder on it.

This way we don't have to copy build.sh scripts all over the place.

Test Plan
  1. git clone the ark repo
  2. run cmake
  3. make/ninja build-flatpak

Diff Detail

Repository
R240 Extra CMake Modules
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
Restricted Application added projects: Frameworks, Build System. · View Herald TranscriptAug 11 2017, 4:23 PM
Restricted Application added subscribers: Build System, Frameworks. · View Herald Transcript
apol edited edge metadata.Aug 11 2017, 4:40 PM

Interesting feature.

I'm not opposed to it, but I have the feeling that it belongs to a different layer, so this means creating a build directory to call flatpak to call cmake. :P
Also the arguments one passes to cmake won't have any effect on the flatpak.

What's the reason you want to work on it? maybe we should work in simplifying the flatpak-builder call?

Main reason is having a simple way to run flatpak-builder with the proper arguments. Otherwise you have to copy-paste the command from somewhere (which could be error-prone).
One usually already has a build folder around, so the idea is you change some code, build it as usual and then you run this target to quickly test the change in flatpak.

apol added a comment.Aug 11 2017, 7:04 PM

Main reason is having a simple way to run flatpak-builder with the proper arguments. Otherwise you have to copy-paste the command from somewhere (which could be error-prone).
One usually already has a build folder around, so the idea is you change some code, build it as usual and then you run this target to quickly test the change in flatpak.

Note that this is forcing that the file is in the root directory, this doesn't need to be necessarily the case. In fact xdg-portal-kde-test has it in a subdir.

This would already do what you're after:
alias fb=flatpak-builder --force-clean --ccache --require-changes --repo=repo app $@

Such an alias/script could go in here: https://cgit.kde.org/kde-dev-scripts.git/

The reason why I'm discussing this is that I think one of the advantages of Flatpak

In D7253#134703, @apol wrote:

Main reason is having a simple way to run flatpak-builder with the proper arguments. Otherwise you have to copy-paste the command from somewhere (which could be error-prone).
One usually already has a build folder around, so the idea is you change some code, build it as usual and then you run this target to quickly test the change in flatpak.

Note that this is forcing that the file is in the root directory, this doesn't need to be necessarily the case. In fact xdg-portal-kde-test has it in a subdir.

This would already do what you're after:
alias fb=flatpak-builder --force-clean --ccache --require-changes --repo=repo app $@

Such an alias/script could go in here: https://cgit.kde.org/kde-dev-scripts.git/

The reason why I'm discussing this is that I think one of the advantages of Flatpak

Did you hit Submit too soon? :p
Anyway, an alias certainly works, I can live with that.

apol added a comment.Aug 13 2017, 5:32 PM

Ugh my bad ^^', I don't know what happened.

The reason why I'm discussing this is that I think one of the advantages of Flatpak

is that it makes it much easier to set up the build environment. Documented dependencies and tooling that integrates it. We need to leverage that rather than hiding it in the current state which while it works it's overly complex and part of a problem to solve.

krop added a subscriber: krop.Aug 14 2017, 7:50 AM
krop added inline comments.
kde-modules/KDECMakeSettings.cmake
361

find_package(Git)
if(Git_FOUND)
execute_process(COMMAND GIT_EXECUTABLE...

else()
print some message

elvisangelaccio abandoned this revision.Aug 14 2017, 4:02 PM
In D7253#135251, @apol wrote:

Ugh my bad ^^', I don't know what happened.

The reason why I'm discussing this is that I think one of the advantages of Flatpak

is that it makes it much easier to set up the build environment. Documented dependencies and tooling that integrates it. We need to leverage that rather than hiding it in the current state which while it works it's overly complex and part of a problem to solve.

This is a good point indeed.