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.

In D7253#134653, @elvisangelaccio 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

In D7253#134703, @apol wrote:

In D7253#134653, @elvisangelaccio 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.

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.