Hi,
I would rather have packagesExist fixed (I also ran into this one, see
https://bugreports.qt-project.org/browse/QTBUG-42499 :)
A (philosophical?) problem is that from Qt's perspective, Sailfish is
not really an
OS - that would be Linux - but merely a distro. Once you start down this
path of
Q_OS_..., one could argue for Q_OS_DEBIAN and Q_OS_REDHAT, etc. What is
(from a developer's perspective) special about SailfishOS is how it is
different from
other Linuxes, hence the package detection being the "right way".
Best regards,
Attila
On 12/4/2014 6:38 PM, Alejandro Exojo wrote:
Hi.
I've asked this a couple of times on IRC, but I haven't found a fully
satisfying answer. I want to see SailfishOS as any other OS/platform is
featured in Qt: by having some qmake support to detect wheter I'm compiling
for SailfishOS or not.
Once that is done, having a Q_OS_SAILFISH preprocessor macro that can also
choose different paths in C++ and adding support in QFileSelector is trivial.
The big question is: do you want such thing in Qt? If yes, I would gladly do
it myself, since I have some time available and I'm looking for ways to
contribute to Qt, learn, etc.
Rationale:
Right now everyone is baking its own way, with varying degrees of success. ;-)
I looked at it a year ago when I started writing my Sailfish application, and
I was pointed to puzzle-master's sources, where a simple
packagesExist(sailfishapp) did the trick... or so I thought. Since I wasn't
testing the non-Sailfish branch much, I didn't realize Creator always returns
true on this condition (by design: not allowed to fork a process when parsing
.pro files). Seems a petty complaint (who cares about Creator that much? it
works for qmake just fine), but with harbour requiring a "harbour-" prefix in
the name of the executable, Creator might not even be able to start the
application because it doesn't find it if you use a different value for
TARGET.
Lately I've been finding time for the app again and I finally noticed the
problem, so I asked on IRC again. I was pointed at other application, and the
check used was even worse. :-)
Then I searched a bit in the branch of the mer-qt/qtbase repo. I see you don't
use any mkspec for SailfishOS or Jolla, right? That's where I thought you
might have it, and where I think it could be. Blackberry sets there the
QMAKE_PLATFORM and Q_OS_BLACKBERRY.
Yes, yes. I know there is a solution: pass a parameter to the qmake
invocation. Store the invocation flag on the RPM packaging for final
deployment, and maybe a .pro.shared file for development. That's what Puzzle
Master has now too. Still I think there is some value in having this sorted
out in a more general way, specially given that you'll want people to also
distinguish a build for the Jolla phone or the Jolla tablet.
Cheers.
_______________________________________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
