I think this is a topic more or less directly addressed to @nephros but I’ll post it here anyway.
I have a number of projects I’d like to add simple dbus (url handler) methods for.
That has, in the past involved:
- extra service files & extra desktop files in pro and or rpm
- import Nemo.DBus 2.0 in qml and rpm
These, of course bar the app from harbour.
Making the files section and Requires conditional for chum is not difficult though it also means a sed on one QML file.
Where it get’s tricky is the pro file, I think. Also, github actions will probably require a bit of a hack, but would probably at least make editing the pro file before the build possible.
Anyone have any thoughts about this?
Ah, that’s cool. Where does the store: [yes, no] value get set?
If i understood correctly, the .pro picks up the harbour_store boolean from the rpm.
That should work. Thanks!
You’re not doing chum, though? I can mix and match though so … I’ll try it tomorrow!
Exactly there, when you do a matrix in GH, it creates a job for every combination of values in the Matrix.
Not in Chum, I read once on how to do that a few years ago, seemed too user unfriendly so I decided to skip it, especially because the Chum GUI has a much worse UX than Storeman.
2 Likes
One trick I use is this (works mainly for QML):
Package everything non-harbour compliant in an rpm subpackage.
Put non-harbour compliant QML stuff in some subdirectory, package that only in the subpackage.
In the main app, use a Loader to attempt to load the non harbour QML files.
The Loader will fail if the subpackage files can not be found, but the main app will continue to function.
Put the main app into Harbour, and the subpackage on Chum (or OpenRepos). Promote the subpackage as a ”Plugin” for the harbour app.
An overly complicated example of this is in lonewolf: lonewolf/app/Main.qml at sfos · nephros/lonewolf · GitHub
lonewolf/app/Main.qml at sfos · nephros/lonewolf · GitHub
A simpler one in maelstrom:
2 Likes
As for building harbour/non-harbour packages on OBS, I do it this way:
Look at the .spec files (especially for lonewolf, or maelstrom) in that OBS project, they use the bcond_with rpm thing to enable dual builds. I.e. they will build harbour-compliant rpms when built in that project, and non-compliant ones everywhere else.
As a bonus, the build process will run the harbour rpm validator and save the output along with the RPMS!
(… although the lonewolf build on chum is currently broken in a weird way on chum for 5.x - older versions do build)
1 Like
… .pro files…
Meh, all build systems suck.
But all should take options or read env vars to control the build, right.
qmake \
FOO=bar \
%if %{with_harbour}
HARBOUR_BUILD=1 \
%endif
%{nil}
Maybe use a .pri file for the non-harbour parts,and include that only if some condition is met?
Or you could always maintain two separate .pros.
Or you could even patch the original .pro from the .spec file, wrapped in some %if macros.
1 Like
Looking through the docs
in the spec, wanting to use the same spec in sdk/github/chum:
qmake \
%if "%{?vendor}" == "chum"
DEFINES += USE_MY_STUFF
INSTALLS+=NONHARBOUR.qml
HARBOUR=0
%endif
Might be sufficient? I can also to INSTALLS+= if I understood correctly?
I dunno.
See this: https://stackoverflow.com/questions/26621709/how-can-i-use-environment-variable-in-a-qt-qmake-file-windows
But you need the backslashes! 
The %{nil} is useful so you can add and remove lines and don’t need to worry about the final backslash.
1 Like
Yes, of course I don’t think this will work as I expect, but I’m trying some variations on it now.
Be aware that the call in the spec is using shell language, not qmake language.
So depending on the shell, FOO+=bar will probably define a variable called FOO+, and not be interpreted by qmake.
Sure. It’s also clear that there will be no recipe that works in sdk/chum/github contexts. I’m going to try the git hub style build @Rikudou_Sennin suggests
@Rikudou_Sennin just to clarify:
The actions line:
HARBOUR_STORE=1 MB2_QMAKE_ARGS='CONFIG+=harbour_store' mb2 -t SailfishOS-$OS_VERSION-${{ matrix.arch }} build --no-check ;
provides the values for the .pro
harbour_store {
DEFINES += ICU_DYNAMIC
} else {
PKGCONFIG += icu-uc icu-i18n
}
block?
@nephros This variant works to get a conditional that works in the sdk.
%if "%{?vendor}" == "chum"
%qtc_qmake5
%qtc_make %{?_smp_mflags}
%else
HARBOUR_STORE=1 MB2_QMAKE_ARGS='CONFIG+=harbour_store' %qtc_qmake5 QMAKE_ARGS='CONFIG+=harbour_store' 'CONFIG+=harbour_store'
HARBOUR_STORE=1 MB2_QMAKE_ARGS='CONFIG+=harbour_store' %qtc_make %{?_smp_mflags} QMAKE_ARGS='CONFIG+=harbour_store' 'CONFIG+=harbour_store'
%endif
No idea which qtc_qmake macro is actually used
harbour_store {
message("Yup store")
} else {
DISTFILES+=harbour-happycamper-open-url.desktop
# extra desktop file for dbus
desktop2.path += /usr/share/applications
desktop2.files = $${TARGET}-open-url.desktop
INSTALLS += desktop2
# extra service file for dbus
service.path = /usr/share/dbus-1/services
serivce.files = de.poetaster.happycamper.service
INSTALLS += service
}
And ‘harbour_store’ get’s picked up in the pro as it does on github with @Rikudou_Sennin recipe.
1 Like
Damn, how many steps of indirection can we go down?? 
.
1 Like
You are NOT kidding. I managed to simplify to
%if "%{?vendor}" == "chum"
%qmake5 VERSION=%{version} RELEASE=%{release}
%else
HARBOUR_STORE=1 MB2_QMAKE_ARGS='CONFIG+=harbour_store' %qmake5 QMAKE_ARGS='CONFIG+=harbour_store' 'CONFIG+=harbour_store'
%endif
for tooter which I can now build normally for harbour (still with the sdk) and on chum it supports the dbus desktop handler. I hope
Now I have to extend the github build method and I should have a fairly nice separation without having to maintain more code. But this is a simple thing. I looked at lonewolf and spent 20 minutes scratching my head. Which is almost as long as I’ve spent playing the game 
EDIT: My goal is always to have a version that can be built in the SDK so that ‘any one’ can build it without knowing github/chum etc ‘foo’.
2 Likes
Yep, that’s exactly the place.
1 Like
All problems can be solved by adding another layer of indirection. Except for the problem of too many indirections.
2 Likes
I had been happy with @coderus clean version 5 github builds and realized that I could not quite use your approach (as taken from https://raw.githubusercontent.com/RikudouSage/harbour-spliit/refs/heads/master/.github/workflows/build.yaml) since it’s diverged a bit.
I’m trying to adapt harbour-tooter/.github/workflows/main.yml at master · poetaster/harbour-tooter · GitHub to your conditional store build matrix and realized that I’d either have to step back to the 4.x variety or maybe ask you if you think your docker run variety can be used with the newer coderus/github-sfos-build@sfos5
Should be possible, ultimately it runs mb2 build as well. So passing e.g. HARBOUR_STORE=1 MB2_QMAKE_ARGS='CONFIG+=harbour_store' like I do should be possible using the env key of github actions, e.g.:
- name: Build aarch64
id: build_aarch64
uses: coderus/github-sfos-build@sfos5
env:
HARBOUR_STORE: 1
MB2_QMAKE_ARGS: 'CONFIG+=harbour_store'
with:
release: ${{ env.RELEASE }}
arch: aarch64
You can of course put it into a matrix which will provide the parameters. Untested, but IMO should work.
I went ahead and tried doing it like spliit does it, trying to remain as close as possible. Workflow runs · poetaster/fibonacci · GitHub It took me a while to realize the lintrc is needed
I does go through the matrix, but the harbour builds (store yes) all fail with
+ %qmak5 CONFIG+=harbour_store
/var/tmp/rpm-tmp.fyJgtg: line 39: fg: no job control
error: Bad exit status from /var/tmp/rpm-tmp.fyJgtg (%build)
Bad exit status from /var/tmp/rpm-tmp.fyJgtg (%build)
Not sure what I’ve managed to miss.
EDIT: and I only saw it after posting it here That’s qmake! not qmak Duh.
EDIT: this builds on chum too, so best of all worlds.
2 Likes