[SailfishDevel] SailfishOS as an OS/platform in Qt
qt at csipa.in.rs
Fri Dec 5 11:51:44 UTC 2014
If there is any difference from running qmake "raw", from the command
from QtCreator, something is amiss (kinda kills the "Integrated" part of
approach). At the very least, it should flash a warning that you are
it cannot comply with (whatever the reasoning - technical or policy).
On 12/5/2014 11:05 AM, Alejandro Exojo wrote:
> El Friday 05 December 2014, Attila Csipa escribió:
>> I would rather have packagesExist fixed (I also ran into this one, see
>> https://bugreports.qt-project.org/browse/QTBUG-42499 :)
> Didn't know that. I found this instead:
> This isn't going to be fixed because is by design that Creator is not going to
> execute things that could have side effects:
> <suy> Why the project file evaluation can't run a separate process?
> Performance? Thinking how to workaround https://bugreports.qt-
> <qt_gerrit> Qt Creator treats packagesExist incorrectly -
> <dt|tt> suy: what does your question have to do with that bug report?
> <suy> dt|tt: you said in the bug report "packagesExists is implemented via a
> $system call. Since we don't want to run arbitrary processes while parsing the
> project (...)"
> <dt|tt> suy: right, it should be self-evident why we don't want to run
> arbitrary processes while parsing a .pro file
> <dt|tt> suy: we don't know what side effects there are
> <suy> dt|tt: not to me, that's why I'm asking. :) I'm not a creator
> developer. I was thinking if qmake can do it, creator can do it, unless the
> trouble is of course that it has to do it again
> <dt|tt> suy: not while parsing the project
> <dt|tt> suy: that would be insane
> <suy> Yes, I though its a security risk. But, well, somebody can still add a
> system() call in a pro file and do nasty things when running qmake, isn't it?
> <dt|tt> suy: parsing needs to be side effect free
> <andre_> suy: it's not just a security risk, it's also executing stuff more
> often and/or at other times than a regular qmake run would. so lots of fancy
> mechanism set up in the .pro are likely to break in that situation.
>> 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".
> Yes, I've given it some thought, and is not an easy to draw line. There is
> certainly a distinction, but one could defend that such detection has to be
> done at runtime instead. For example, a dialog in KDE has a different
> OK/Cancel ordering than in GNOME (and different look, etc.). The binary might
> be the same, but the application chooses behaviour at runtime.
> I thought that Sailfish might be a different than a simple "environment where
> the app might be executed" in that it has some platform specific libraries
> (libsailfishapp, booster). Also, the fact that Blackberry 10 is treated
> different than QNX, so they have the boilerplate set up. I'll see what the
> Ubuntu Touch people do.
More information about the Devel