If there is any difference from running qmake "raw", from the command
line, and
from QtCreator, something is amiss (kinda kills the "Integrated" part of
the IDE
approach). At the very least, it should flash a warning that you are
doing something
it cannot comply with (whatever the reasoning - technical or policy).
Attila
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:
https://bugreports.qt-project.org/browse/QTCREATORBUG-11510
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-
project.org/browse/QTCREATORBUG-11510
<qt_gerrit> Qt Creator treats packagesExist incorrectly -
https://bugreports.qt-project.org/browse/QTCREATORBUG-11510
<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.
_______________________________________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
