Re: [Development] Dependencies of Qt5

[Konstantin Ritt]

OR can we have pre-generated sources (for ANGLE at very least)?

Konstantin


2012/10/31 Thiago Macieira :
> On quarta-feira, 31 de outubro de 2012 16.51.03, Simon Hausmann wrote:
>> > > The issue comes from GnuWin32 having a version of flex that is too old
>> > > for
>> > > Angle. In WebKit land we've told people to install the GNU tools from
>> > > the
>> > > GnuWin32 distribution (gperf, etc.) and unfortunately the version there
>> > > is
>> > > outdated. Hence the discovery of win_flex.
>> > >
>> > >
>> > >
>> > > I suppose a better solution would be to have a real configure check for
>> > > flex in  qtbase and see if the version in PATH is new enough. We can
>> > > still try to use a copy of qt5.git/gnuwin32 as fallback if we can locate
>> > > it.
>> >
>> > What is the minimum required version?
>>
>> I'm not exactly sure, but I know that 2.5.4 is too old (generated code
>> won't  compile) and 2.5.35 seems to work well.
>
> That's the one that comes with msysgit. Can we make the buildsystem use "flex"
> if flex is available instead?
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pending decisions on co-installation

[Thiago Macieira]

On quinta-feira, 1 de novembro de 2012 11.56.25, Lincoln Ramsay wrote:
> On 01/11/12 09:41, Thiago Macieira wrote:
> > On quinta-feira, 1 de novembro de 2012 09.23.37, Lincoln Ramsay wrote:
> >> On 01/11/12 01:02, Thiago Macieira wrote:
> >>> Also, do I understand correctly that you're suggesting that multiarch
> >>> 
> >>> distributions should have *both*:
> >>>   /usr/lib/qt5//bin/assistant AND 
> >>> /usr/lib64/qt5/bin/assistant
> >>>   /usr/lib/qt5//bin/linguist  AND 
> >>> /usr/lib64/qt5/bin/linguist
> >>>   /usr/lib/qt5//bin/designer  AND 
> >>> /usr/lib64/qt5/bin/designer
> >> 
> >> hang on... why shouldn't they have both of those?
> >> 
> >> a 32-bit assistant is different to a 64-bit assistant
> > 
> > How are they different?
> 
> Well for one thing, you can't run the 32-bit one against a 64-bit
> install or vice versa. Any plugins they load (including system style
> plugins) must be the same bit-ness. Designer used to load plugins for
> custom widgets... not sure if it still does.

Sure, you can't run against the wrong install. But the presence of the 
executable assumes that its dependencies are present and properly installed. 
So that's not an argument. This is how Linguist, Assistant, xmlpatterns, 
xmlpatternsvalidator, qglinfo, qdbus, and qdbusviewer go. Their purpose is 
completely independent of the arch.

The plugin argument for Designer has been discussed. So far, our conclusion is 
to punt the problem because QtWidgets is in Done state. We've punted the 
problem to the plugins themselves: we're requiring that the plugins be updated 
to Qt 5, along with Designer itself.

Designer's output (the .ui file) is arch-independent and even backwards 
compatible. As QtWidgets and Designer are in Done, we're not expecting any new  
features. But even if some come along, the precedent set by tools like 
Microsoft Word and Libre Office is that you simply provide an option in the 
Save 
dialog to save as the previous version.

Heck, I thought Designer in Qt 4 still had the option to save as a Qt 3 .ui 
file, for uic3. I can't find it, though.

Also note that, unlike uic3, uic does not load plugins, so all the information 
it needs to generate the .h file is already present in the .ui. Therefore, if 
the plugins are updated to Qt 5 and they themselves retain their compatibility 
of purpose, a file saved by Designer/Qt5 will be processed correctly by 
uic/Qt4.

> If you're on a 64-bit distro, you most likely don't want the 32-bit
> versions. If you're on a 32-bit distro, you can't use the 64-bit ones.
> That's a distro/packaging problem though. The best we could do is to
> remove these from the Qt repo and build/packge them separately (like we
> do with Creator).

Right, that's a packaging problem. But it's a problem that has been solved by 
distributions when they first came up with multiarch.

For example, for Fedora, a file may belong to both arches, but the 64-bit one 
wins:

$ rpm -qf /usr/bin/mysql_config 
mysql-5.5.28-1.fc17.x86_64
mysql-5.5.28-1.fc17.i686

$ file /usr/bin/mysql_config 
/usr/bin/mysql_config: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), 
dynamically linked (uses shared libs), for GNU/Linux 2.6.32, 
BuildID[sha1]=0x815aa7c206d463b192ed09b42965796b4f2e4d05, stripped

If designer exists in one common path, outside of LIBDIR, the existing 
multiarch mechanisms kick in and fix the problem of duplication.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pending decisions on co-installation

[Thiago Macieira]

On quinta-feira, 1 de novembro de 2012 11.39.22, Chris Adams wrote:
> You're right.
> Ok, all in all, I think having separate import install paths and separate
> envvars to define the import path basedir at runtime is the best solution
> after all.

Thanks. That makes my life easier because there's no need to patch further. 
The only variable I've renamed so far was QML_PLUGIN_PATH.

I'm still waiting for the final decision on the tooling. The current 
suggestions are:

qml1viewer (from qmlviewer)
qml2viewer (from qmlscene)
qml1plugindump
qml2plugindump (from qmlplugindump)

All the rest is unchanged.

Please note that we *can* have qmlviewer, provided it's the Qt Quick 1. It 
works in either scenario of tooling: if it's in $PATH, it's via the 
toolwrapper, in which case you run the Qt 5 version by adding the -qt5 option.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pending decisions on co-installation

[Lincoln Ramsay]

On 01/11/12 09:41, Thiago Macieira wrote:
> On quinta-feira, 1 de novembro de 2012 09.23.37, Lincoln Ramsay wrote:
>> On 01/11/12 01:02, Thiago Macieira wrote:
>>> Also, do I understand correctly that you're suggesting that multiarch
>>>
>>> distributions should have *both*:
>>> /usr/lib/qt5//bin/assistant AND 
>>> /usr/lib64/qt5/bin/assistant
>>> /usr/lib/qt5//bin/linguist  AND 
>>> /usr/lib64/qt5/bin/linguist
>>> /usr/lib/qt5//bin/designer  AND 
>>> /usr/lib64/qt5/bin/designer
>> hang on... why shouldn't they have both of those?
>>
>> a 32-bit assistant is different to a 64-bit assistant
> How are they different?

Well for one thing, you can't run the 32-bit one against a 64-bit 
install or vice versa. Any plugins they load (including system style 
plugins) must be the same bit-ness. Designer used to load plugins for 
custom widgets... not sure if it still does.

If you're on a 64-bit distro, you most likely don't want the 32-bit 
versions. If you're on a 32-bit distro, you can't use the 64-bit ones. 
That's a distro/packaging problem though. The best we could do is to 
remove these from the Qt repo and build/packge them separately (like we 
do with Creator).

-- 
Link

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Status of WP8 port

[Yang Fan]

Nobody knows. Since Nokia sold Qt, the development progress is slower
and slower and slower...

On Wed, Oct 31, 2012 at 5:09 PM, Pau Garcia i Quiles
 wrote:
> Hello,
>
> Microsoft has released the Windows Phone 8.0 SDK with native support.
>
> http://blogs.windows.com/windows_phone/b/wpdev/archive/2012/10/30/announcing-the-new-windows-phone-8-developer-platform.aspx
>
> https://dev.windowsphone.com/en-us/downloadsdk
>
>
> What's the status of Qt 5 on WP8? Last I remember, a feasibility study
> was being carried on. What was the outcome?
>
> --
> Pau Garcia i Quiles
> http://www.elpauer.org
> (Due to my workload, I may need 10 days to answer)
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



-- 
Regards,
Fan Yang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pending decisions on co-installation

[Chris Adams]

On Thu, Nov 1, 2012 at 10:56 AM, Thiago Macieira
wrote:

> On quinta-feira, 1 de novembro de 2012 10.01.11, Chris Adams wrote:
> > Regarding QML_IMPORT_PATH, I discussed this yesterday and this morning
> with
> > Martin Jones and Andrew den Exter, and a couple of things deserve
> > mentioning:
> > 1) through the versioning of imports (ie, the path lookup with
> major/minor
> > version appended to module name) a client can create a QML1
> > (QDeclarativeExtensionPlugin) module plugin and install it into, say,
> > "$QML_IMPORT_PATH/com/examplecompany/examplemodule1/" and then create a
> > QML2 (QQmlExtensionPlugin) module plugin and install it into
> > "$QML_IMPORT_PATH/com/examplecompany/examplemodule2/", and this will work
> > fine.
> >
> > That is, the QML_IMPORT_PATH need not be different (or set differently)
> > between applications using QML1 and QML2, so long as they import the
> > modules of the correct version (ie, for the version of QML against which
> > their application is written).
>
> That assumes that there is a different module name or version number, which
> isn't always the case. Qt Quick did decide to break source compatibility by
> requiring "import QtQuick 2", but the same does not follow for other
> imports.
>

I guess that's true.  But I would argue that any 3rd party module developer
who _doesn't_ bump the version of their newly updated module when they
rewrite it for a new major version of QML is probably doing their customers
a major disservice (since the API of every element they provide will most
likely have changed dramatically - even if they themselves didn't add or
remove any API - unless the types they provide merely extend QObject
instead of QDeclarativeItem / QQuickItem).

But you are right.  The versioning of the module and the versioning of the
language are separate, and in the case that they aren't using the QtQuick
primitives, for example, the API offered by types provided by a 3rd party
module may remain unchanged, and thus the version should remain unchanged
also.  I withdraw my argument for my previous stance ;-)


>
> Note that there already was a separate import path for Qt Quick 1 by
> appending
> "QtQuick1" to the paths found in QML_IMPORT_PATH. And it is used by some
> code
> that we install ourselves, like Qt.labs.folderlistmodel.
>
> $ cat imports/Qt/labs/folderlistmodel/qmldir
> plugin qmlfolderlistmodelplugin
>
> $ cat qml/Qt/labs/folderlistmodel/qmldir
> module Qt.labs.folderlistmodel
> plugin qmlfolderlistmodelplugin
> typeinfo plugins.qmltypes
>

Unfortunately, folderlistmodel was never properly maintained.  I don't know
if we bumped the version of it correctly, for example, which is why it
looks like it hasn't been installed into a folderlistmodel2 directory.  I'm
not sure what you mean by the "appending QtQuick1 to the paths found in
QML_IMPORT_PATH" -- you mean, in our code at plugin loading time in
importdatabase or something?  I don't remember that code too well, but
arbitrarily changing the import path supplied by the user seems like a bad
idea (eg, we can't guarantee that the client has the module they want,
installed into QML_IMPORT_PATH/qtquick1 instead of just QML_IMPORT_PATH
etc).  But I've probably misunderstood what you meant here, can you clarify?

In any case, given your previous point (that is, that the version of
modules needn't be bumped, necessarily, just because the version of QML
changed, if their API remains unchanged) I now am forced to agree with your
point that the import paths do need to be separate, for this
3rd-party-module-versioning reason.


>
>
> > So, I'm not sure that QML_IMPORT_PATH needs to be versioned, so long as
> > QML's imports versioning system works as expected in future versions.
> > I'm not sure that we need to have a qt5/imports dir for QML1 plugins and
> a
> > separate qt5/qml dir for QML2 plugins, since coexisting qq1/qq2 plugins
> > worked previously according to versioning, with the same import path.
>
> No, they didn't. They already had different import paths before I started
> doing
> anything. All I did was change the paths searched and the environment
> variables that supply the paths.
>

> > A
> > problem might occur if you set QML_IMPORT_PATH to point to a qt4 (QML1)
> > import path, and then run a qt5 QML1 application - it'll be trying to
> load
> > QML1 plugins built against qt4, which will fail.
>
> Indeed, but hopefully the Qt plugin system will simply refuse to load the
> plugins, avoiding a crash. The QML plugins *are* Qt plugins, loaded via
> QPluginLoader, aren't they?
>

Yes, we use QPluginLoader to load plugins in
qdeclarativeimport.cpp/qqmlimport.cpp.


>
> This is the same situation with QT_PLUGIN_PATH, which is unversioned.
> However,
> the plugin magic is incompatible between Qt 4 and 5, so we can keep the
> same
> environment variable, which contains both sets of plugin paths. Qt 4 will
> not
> load Qt 5 plugins and Qt 5 will not load Qt 4 plugins.
>

Right.


>
> > Anyway, the long and

Re: [Development] Pending decisions on co-installation

[Thiago Macieira]

On quinta-feira, 1 de novembro de 2012 10.01.11, Chris Adams wrote:
> Regarding QML_IMPORT_PATH, I discussed this yesterday and this morning with
> Martin Jones and Andrew den Exter, and a couple of things deserve
> mentioning:
> 1) through the versioning of imports (ie, the path lookup with major/minor
> version appended to module name) a client can create a QML1
> (QDeclarativeExtensionPlugin) module plugin and install it into, say,
> "$QML_IMPORT_PATH/com/examplecompany/examplemodule1/" and then create a
> QML2 (QQmlExtensionPlugin) module plugin and install it into
> "$QML_IMPORT_PATH/com/examplecompany/examplemodule2/", and this will work
> fine.
> 
> That is, the QML_IMPORT_PATH need not be different (or set differently)
> between applications using QML1 and QML2, so long as they import the
> modules of the correct version (ie, for the version of QML against which
> their application is written).

That assumes that there is a different module name or version number, which 
isn't always the case. Qt Quick did decide to break source compatibility by 
requiring "import QtQuick 2", but the same does not follow for other imports.

Note that there already was a separate import path for Qt Quick 1 by appending 
"QtQuick1" to the paths found in QML_IMPORT_PATH. And it is used by some code 
that we install ourselves, like Qt.labs.folderlistmodel.

$ cat imports/Qt/labs/folderlistmodel/qmldir 
plugin qmlfolderlistmodelplugin

$ cat qml/Qt/labs/folderlistmodel/qmldir
module Qt.labs.folderlistmodel
plugin qmlfolderlistmodelplugin
typeinfo plugins.qmltypes


> So, I'm not sure that QML_IMPORT_PATH needs to be versioned, so long as
> QML's imports versioning system works as expected in future versions.
> I'm not sure that we need to have a qt5/imports dir for QML1 plugins and a
> separate qt5/qml dir for QML2 plugins, since coexisting qq1/qq2 plugins
> worked previously according to versioning, with the same import path.

No, they didn't. They already had different import paths before I started doing 
anything. All I did was change the paths searched and the environment 
variables that supply the paths.

> A
> problem might occur if you set QML_IMPORT_PATH to point to a qt4 (QML1)
> import path, and then run a qt5 QML1 application - it'll be trying to load
> QML1 plugins built against qt4, which will fail.

Indeed, but hopefully the Qt plugin system will simply refuse to load the 
plugins, avoiding a crash. The QML plugins *are* Qt plugins, loaded via 
QPluginLoader, aren't they?

This is the same situation with QT_PLUGIN_PATH, which is unversioned. However, 
the plugin magic is incompatible between Qt 4 and 5, so we can keep the same 
environment variable, which contains both sets of plugin paths. Qt 4 will not 
load Qt 5 plugins and Qt 5 will not load Qt 4 plugins.

> Anyway, the long and short of it is -- these variables / configure options
> are all developer-facing, so to be honest, we don't think it's a huge issue
> to change them if we want to, or leave them (and document the differences
> if required) if that is simpler or less confusing.

All of them except for QML_IMPORT_PATH. That can be expected to be set on a 
production system, like some other variables that modify Qt's behaviour post-
installation:

QT_PLUGIN_PATH
QT_QPA_PLATFORM_PLUGIN_PATH
QT_QPA_PLATFORM
QT_MESSAGE_PATTERN

For example, my default shell environment has:

$ echo $QT_PLUGIN_PATH 
/home/thiago/obj/qt/qt-4.8-
release/plugins:/home/thiago/kde/lib/kde4/plugins:/usr/lib64/qt4/plugins:/home/thiago/.kde/lib/kde4/plugins/:/home/thiago/kde/lib/kde4/plugins/:/usr/lib/kde4/plugins/:/home/thiago/kde/lib/plugins/:/usr/lib64/kde4/plugins

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pending decisions on co-installation

[Chris Adams]

Hi,

On Wed, Oct 31, 2012 at 8:17 PM, Sune Vuorela  wrote:

> On 2012-10-30, Thiago Macieira  wrote:
> > 1) QML environment variables
> > The variable for import paths has been versioned from QML_IMPORT_PATH to
> > QML2_IMPORT_PATH. But I have not changed any of the other variables. We
> need a
> > decision from the team familiar with the engines and the meanings of
> those
> > variables to know which ones should be versioned too.
> >
> > They need to be versioned if having a value set in it applies to one QML
> > engine but has ill-effects for the other.
>
> isn't 'not versioning this' a recipe for disaster for both end users of
> applications and for developers of applications if we don't do something
>

Only if the meaning of the variable or config option changes in different
versions.  Most of the ones that I can think of from the top of my head are
applicable in the same way to both QML1 and QML2 (for example,
QML_COMPILER_STATS, QML_COMPILER_DUMP, QML_IMPORT_TRACE are all just
debugging helpers which cause statistics or extra information to be emitted
from the engine), however some others deserve closer inspection:

Compiler / Bindings / VM / JS:
QML_DISABLE_OPTIMIZER: disables v4 in QML2, disables "compiledbindings" in
QML1.  In the future, with v4vm or similar, this might mean "use v8 instead
of v4vm" in QML2...
QML_DISABLE_FAST_PROPERTIES: this config option was QML1 only, and
determined whether fast JS accessors for QObject properties were installed,
I believe.
QML_VERBOSE_COMPILER: verbose output from v4 in QML2 when building the IR
QML_BINDINGS_TEST: verbose output from v4 in QML2 creating binding
assignments
QML_REWRITE_DUMP: verbose output from bindings/signal handlers expression
rewriter in both QML1 and QML2
QML_BINDINGS_DUMP: verbose output from compiler in QML1 only
QML_CHECK_TYPES: check for typename clashes in both QML1 and QML2
QML_DUMP_ERRORS: output any errors which occurred during typeloading in
QML2 instead of just appending to engine's warning list

Other:
QML_DISABLE_DISTANCEFIELD: the distancefield text rendering is new to Qt5,
I believe, so this config option was added in QML2.
QML_ENABLE_TEXT_IMAGE_CACHE: in QML1 only, although we still do text image
caching in some situations in QML2
QML_FBO_OVERLAY: QML2 only, related to shaders
QML_XHR_DUMP: QML1 and QML2, for debugging xml http requests
QML_VISUAL_TOUCH_DEBUGGING: QML2 only, for debugging touch and mouse events

Scene graph related (QML2 only) - I don't really know what these do in
detail, although most seem fairly self explanatory:
QML_FLASH_MODE
QML_TRANSLUCENT_MODE
QML_DEBUG_LEAK_BACKTRACE
QML_FORCE_THREADED_RENDERER and its amusing twin QML_BAD_GUI_RENDER_LOOP
QML_RENDERER_TIMING
QML_FIXED_ANIMATION_STEP
QMLSCENE_DEVICE

and finally the infamous QML_IMPORT_PATH.

Regarding QML_IMPORT_PATH, I discussed this yesterday and this morning with
Martin Jones and Andrew den Exter, and a couple of things deserve
mentioning:
1) through the versioning of imports (ie, the path lookup with major/minor
version appended to module name) a client can create a QML1
(QDeclarativeExtensionPlugin) module plugin and install it into, say,
"$QML_IMPORT_PATH/com/examplecompany/examplemodule1/" and then create a
QML2 (QQmlExtensionPlugin) module plugin and install it into
"$QML_IMPORT_PATH/com/examplecompany/examplemodule2/", and this will work
fine.

That is, the QML_IMPORT_PATH need not be different (or set differently)
between applications using QML1 and QML2, so long as they import the
modules of the correct version (ie, for the version of QML against which
their application is written).

So, I'm not sure that QML_IMPORT_PATH needs to be versioned, so long as
QML's imports versioning system works as expected in future versions.
I'm not sure that we need to have a qt5/imports dir for QML1 plugins and a
separate qt5/qml dir for QML2 plugins, since coexisting qq1/qq2 plugins
worked previously according to versioning, with the same import path.  A
problem might occur if you set QML_IMPORT_PATH to point to a qt4 (QML1)
import path, and then run a qt5 QML1 application - it'll be trying to load
QML1 plugins built against qt4, which will fail.

Anyway, the long and short of it is -- these variables / configure options
are all developer-facing, so to be honest, we don't think it's a huge issue
to change them if we want to, or leave them (and document the differences
if required) if that is simpler or less confusing.


>
> >
> > 2) QML tool names
> > Kai raised the point that many of the QML 2 tools work for QML 1 too and
> maybe
> > even for Qt 4's QML 1. We need confirmation on that as well as the
> willingness
> > to keep them that way for one or two years at least. For the tools that
> work
> > on both QML engines, we can drop the version number from their names.
>
> ack.
>

Again, most of these tools are developer-facing, so renaming them isn't a
huge issue, in our opinion.
I think it is a bit ugly that you can't tell from the name whether
someth

Re: [Development] Pending decisions on co-installation

[Thiago Macieira]

On quinta-feira, 1 de novembro de 2012 09.23.37, Lincoln Ramsay wrote:
> On 01/11/12 01:02, Thiago Macieira wrote:
> > Also, do I understand correctly that you're suggesting that multiarch
> > 
> > distributions should have *both*:
> > /usr/lib/qt5//bin/assistant AND 
> > /usr/lib64/qt5/bin/assistant
> > /usr/lib/qt5//bin/linguist  AND 
> > /usr/lib64/qt5/bin/linguist
> > /usr/lib/qt5//bin/designer  AND 
> > /usr/lib64/qt5/bin/designer
> 
> hang on... why shouldn't they have both of those?
> 
> a 32-bit assistant is different to a 64-bit assistant

How are they different?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pending decisions on co-installation

[Lincoln Ramsay]

On 01/11/12 01:02, Thiago Macieira wrote:
> Also, do I understand correctly that you're suggesting that multiarch
> distributions should have *both*:
>   /usr/lib/qt5//bin/assistant AND 
> /usr/lib64/qt5/bin/assistant
>   /usr/lib/qt5//bin/linguist  AND 
> /usr/lib64/qt5/bin/linguist
>   /usr/lib/qt5//bin/designer  AND 
> /usr/lib64/qt5/bin/designer

hang on... why shouldn't they have both of those?

a 32-bit assistant is different to a 64-bit assistant

If the user wants to install both, they should both be present

-- 
Link

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Versioning is not working for custom Qt5 addons

[Denis Shienkov]

Hello all.

When creating a custom add-on for Qt5 not correctly applied version 
number for the target.

For example, file /modules/qt_myaddon.pri have following content:

...
QT.myaddon.VERSION = 1.0.0
QT.myaddon.MAJOR_VERSION = 1
QT.myaddon.MINOR_VERSION = 0
QT.myaddon.PATCH_VERSION = 0
...

and *pro file have:

...
load(qt_build_config)
...
#VERSION = $$QT.myaddon.VERSION #1.0.0
...
load(qt_module)
...

But, after building i've getting the version 5.0.0 for my dll/so target 
library,
although the directory for private headers have name 1.0.0.

Also, if i'm add VERSION = $$QT.myaddon.VERSION It no make sense because 
QT.myaddon.VERSION is empty,
(even after load(qt_module) directive).

Work only directly setup
...
VERSION = 1.0.0
...

Please, help me, Is there a solution?

Best regards,
Denis
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Dependencies of Qt5

[Thiago Macieira]

On quarta-feira, 31 de outubro de 2012 16.51.03, Simon Hausmann wrote:
> > > The issue comes from GnuWin32 having a version of flex that is too old
> > > for
> > > Angle. In WebKit land we've told people to install the GNU tools from
> > > the
> > > GnuWin32 distribution (gperf, etc.) and unfortunately the version there
> > > is
> > > outdated. Hence the discovery of win_flex.
> > >
> > > 
> > >
> > > I suppose a better solution would be to have a real configure check for
> > > flex in  qtbase and see if the version in PATH is new enough. We can
> > > still try to use a copy of qt5.git/gnuwin32 as fallback if we can locate
> > > it.
> > 
> > What is the minimum required version?
> 
> I'm not exactly sure, but I know that 2.5.4 is too old (generated code
> won't  compile) and 2.5.35 seems to work well.

That's the one that comes with msysgit. Can we make the buildsystem use "flex" 
if flex is available instead?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Request for a new playground project

[João Abecasis]

Jarkko Laitinen wrote:
> I have been developing a cloud integration module for Qt. The working name
> for the project is QCloud. It provides an API to do requests to Amazons S3
> and Windows Azure. This has been my masters thesis project and it has been
> done with consultation from Digia. The project is in that kind of a state
> that it could be uploaded to playground. I am not sure what the project
> should contain when it is uploaded to the playground, documentation is
> almost done but tests are still incomplete. I will include a readme that
> helps with the installation and the documentation should provide enough
> information for the developers on how to use the module. I am happy to
> answer more questions if there are any.

What are your plans for this project going forward?


João
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pending decisions on co-installation

[Thiago Macieira]

On quarta-feira, 31 de outubro de 2012 12.23.27, Oswald Buddenhagen wrote:
> > 4) new installation paths (besides the bin directory)
> > The latest patch I've provided creates a grouping of all arch-dependent
> > files  in ARCHDATADIR, with arch-independent files in DATADIR. That
> > change, by itself, is innocuous since it doesn't produce any difference
> > in installation.>
> > 
> >
> > The decision we need is on the defaults for those two directories. My
> > proposal  is to have ARCHDATADIR=LIBDIR/qt5 and DATADIR=PREFIX/share/qt5
> > on Unix build that require make install *only*. Again, there are
> > arguments for and against, so let's hear them.
> >
> > 
> 
> -2
> 
> it's just pointless to change the defaults (because it's trivial for
> distros to adjust the paths, and diversity does not hurt in any way),
> and it's counterproductive to introduce inconsistency in the defaults
> between installed and non-installed builds.

I can accept that we shouldn't change the defaults based on whether we're 
doing make install or not.

The reason I wanted them as the default was so that a minimal "configure --
prefix=/usr" would do the right thing, as most other packages do. That means 
our instructions to packagers are simpler. They need to pass additional -
xxxdir options if they *choose* to according to their distro policies, not 
because our defaults are incorrect.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pending decisions on co-installation

[Thiago Macieira]

On quarta-feira, 31 de outubro de 2012 08.02.20, Thiago Macieira wrote:
> On quarta-feira, 31 de outubro de 2012 12.23.27, Oswald Buddenhagen wrote:
> > > 3) library versioning (i.e., adding "5" to the library name)
> >
> >
> >
> > -1
> >
> >
> >
> > renaming is unnecessary:
> > - there is no problem at all at run-time
> > - the problem at build time is solved by -L flags. there is no need for
> >
> >   an unversioned symlink in /usr/lib.
> >
> > renaming is a bit disruptive:
> > - projects not done with qmake need adjustment/ifdefs
> >
> >   - but then, they probably need adjustment anyway due to the libraries
> > having been split, etc.
>
> Ossi: let me ask you something then: do you want our make install to manage
> both /usr/lib and /usr/lib/qt5/lib?
>
> If so, we need to know about both build dirs and therefore we need --
> prefix=/usr on installations.
>
> If not, I am going to require you to write a script for distros installing
> each Qt tarball so that they do the right thing for each library and it
> does  not hardcode anything.
>
> My argument is that the split is necessary because we're being asked to
> manage  all of this. I'm also with Ján here that trying to override the
> default search paths is troublesome. Some less sophisticated buildsystems
> might add - L/usr/lib64 due to other dependencies saying that is necessary,
> then all of a sudden the application will start linking to Qt 4.
>
> (on OpenSUSE) $ mysql_config --libs
> -L/usr/lib64 -lmysqlclient -lpthread -lz -lm -lrt -lssl -lcrypto -ldl
>
> Mark my words: this is a recipe for disaster.

Here's another reason why we need to manage our libraries properly: cmake and
pkg-config files.

With the library renaming proposed above, distributions can set --
libdir=/usr/lib, /usr/lib64, /usr/lib/x86-64-gnu-linux/, etc. That will
install the *.so files in LIBDIR, where they could conflict with the Qt 4 files
if they aren't renamed.

Setting LIBDIR to /usr/lib/qt5/lib (or equivalent) means the CMake and pkg-
config files get installed to /usr/lib/qt5/lib/{cmake,pkgconfig}, which is not a
path that those systems search by default. That means users of those systems
need to know where Qt 5 is installed in the first place. That defeats the
purpose of having those files in the first place, which is to tell those 3rd-
party build systems how to find Qt.

If we don't rename the libraries, we need to add more options to configure:
cmakedir, pkgconfigdir and who knows what else in the future.
--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pending decisions on co-installation

[Thiago Macieira]

On quarta-feira, 31 de outubro de 2012 20.31.57, André Pönitz wrote:
> > And if we define the cut as the ones that have compatibility of
> > purpose and output, versus the ones that don't?
>
> This sounds not overly wrong as it would reduce some possibly
> needless duplication and reduction in diskspace.
>
> On the other hand, I am not really sure it would be worthwhile.
> On the machine in front of me I have e.g. /usr/bin/designer-qt4
> (symlinked via /etc/alternatives/designer and /usr/bin/designer)
> with 422584 bytes, assistant with 965092 etc. So the total "shared"
> set is in the single digit MB range per installed version of Qt
> (minus 1).
>
> Is this really worth the hassle compared to putting everything
> into the same sandbox?

Yes. If we can do it and do it cleanly, why not?

Don't tell me it's difficult. It's done now and it works.

Alberto has suggested that we ensure that all executables are in
ARCHDATADIR/bin and we manage a few via symlinks or wrapping in PREFIX/bin. I
don't like the idea because I don't see the need to have the executables in
both bin directories, but that is a solution I could live with.

I disagree with leaving /usr/bin unmanaged at all. I want to hear the
arguments on why we should not manage that on "make install".

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pending decisions on co-installation

[André Pönitz]

On Tue, Oct 30, 2012 at 05:06:33PM -0700, Thiago Macieira wrote:
> On terça-feira, 30 de outubro de 2012 23.52.08, André Pönitz
> wrote:
> > On Tue, Oct 30, 2012 at 01:47:03PM -0700, Thiago Macieira wrote:
> > > 5) executable split between end-user applications and indirect
> > > tooling The most controversial proposal so far is to split the
> > > binaries into two groups: one that gets installed to
> > > PREFIX/bin, containing the executables for applications run
> > > directly by the user and which retain backwards compatibility
> > > of purpose, and one that gets installed to ARCHDATADIR/bin
> > > that contains the tools that users generally do not run
> > > directly and which are specific to a particular build of Qt.
> > > Please note that, in the current implementation, like in #4
> > > above, most people on this list will not see a change, as it
> > > applies to Unix builds that require make install *only*.
> > > 
> > > This proposal has met with vehement opposition and I'd like to
> > > hear why.
> > 
> > "There is no clear cut between applications directly run by the
> > users and those that are generally not run directly. In some
> > cases it is clear, in some others it depends on the actual
> > user's habits, and no matter where a cut is made for someone it
> > will be wrong."
> 
> And if we define the cut as the ones that have compatibility of
> purpose and output, versus the ones that don't?

This sounds not overly wrong as it would reduce some possibly
needless duplication and reduction in diskspace.

On the other hand, I am not really sure it would be worthwhile.
On the machine in front of me I have e.g. /usr/bin/designer-qt4
(symlinked via /etc/alternatives/designer and /usr/bin/designer)
with 422584 bytes, assistant with 965092 etc. So the total "shared"
set is in the single digit MB range per installed version of Qt
(minus 1). 

Is this really worth the hassle compared to putting everything
into the same sandbox?

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] FOSDEM CrossDesktop DevRoom 2013 - Call for Talks

[Pau Garcia i Quiles]

Hello,

The Call for Talks for the CrossDesktop DevRoom at FOSDEM 2013 is now
officially open. Please do not wait till the last minute!

--8<---

*

FOSDEM is one of the largest gatherings of Free Software contributors in
the world and happens each February in Brussels (Belgium). One of the
tracks will be the CrossDesktop DevRoom, which will host Desktop-related
talks.

We are now inviting proposals for talks about Free/Libre/Open-source
Software on the topics of Desktop development, Desktop applications and
interoperativity amongst Desktop Environments. This is a unique opportunity
to show novel ideas and developments to a wide technical audience.

Topics accepted include, but are not limited to: Enlightenment, Gnome, KDE,
Unity, XFCE, Windows, Mac OS X, general desktop matters, applications that
enhance desktops and web (when related to desktop).

Talks can be very specific, such as developing mobile applications with Qt
Quick; or as general as predictions for the fusion of Desktop and web in 5
years time. Topics that are of interest to the users and developers of all
desktop environments are especially welcome. The FOSDEM 2012 schedule might
give you some inspiration:

https://archive.fosdem.org/2012/schedule/track/crossdesktop_devroom.html
 

Please include the following information when submitting a proposal:


   -

   Your name
   -

   The title of your talk (please be descriptive, as titles will be listed
   with around 250 from other projects)
   -

   Short abstract of one or two paragraphs
   -

   Short bio
   -

   Requested time: from 15 to 45 minutes. Normal duration is 30 minutes.
   Longer duration requests must be properly justified.


The deadline for submissions is December 14th 2012. FOSDEM will be held on
the weekend of 2-3 February 2013. Please submit your proposals to
crossdesktop-devr...@lists.fosdem.org (subscribtion page for the mailing
list: https://lists.fosdem.org/listinfo/crossdesktop-devroom )

-- The CrossDesktop DevRoom 2013 Organization Team*

--8<---

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Dependencies of Qt5

[Simon Hausmann]

On Wednesday, October 31, 2012 07:38:27 AM Thiago Macieira wrote:
> On quarta-feira, 31 de outubro de 2012 10.28.12, Simon Hausmann wrote:
> > > Simon: what's the difference between flex and win_flex? Note that
> > > there's
> > > a
> > > flex with msysgit, so if we used flex instead of win_flex, it would make
> > > setups easier.
> > 
> > The issue comes from GnuWin32 having a version of flex that is too old for
> > Angle. In WebKit land we've told people to install the GNU tools from the
> > GnuWin32 distribution (gperf, etc.) and unfortunately the version there is
> > outdated. Hence the discovery of win_flex.
> > 
> > I suppose a better solution would be to have a real configure check for
> > flex in  qtbase and see if the version in PATH is new enough. We can
> > still try to use a copy of qt5.git/gnuwin32 as fallback if we can locate
> > it.
> What is the minimum required version?

I'm not exactly sure, but I know that 2.5.4 is too old (generated code won't 
compile) and 2.5.35 seems to work well.


Simon
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] MinGW-builds in CI system (Qt 5)

[Koehne Kai]

> -Original Message-
> From: Anttila Janne
> Sent: Wednesday, October 31, 2012 2:27 PM
> To: Koehne Kai; Piippo Samuli
> Cc: development@qt-project.org; net...@gmail.com
> Subject: RE: MinGW-builds in CI system (Qt 5)
> 
> [...] 
> Since we are currently limited on capacity we cannot do all of these right
> now.
> I'm afraid that MinGW CI support drops to that category and we need to
> wait for HW from Brisbane to arrive...

Fully understood. Just wanted to make sure it's on the table :)

Thanks for your efforts

Kai 

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pending decisions on co-installation

[Thiago Macieira]

On quarta-feira, 31 de outubro de 2012 09.46.18, Alberto Mardegan wrote:
> On 10/31/2012 01:06 AM, Thiago Macieira wrote:
> > In any case, what's the problem with making a subjective decision? Clearly
> > the applications need to be split in two groups, so why shouldn't the Qt
> > Project make its recommendation to the downstreams?
> 
> I would like that all binaries are installed in ARCHDATADIR/bin, so that
> they can be all easily accessed with a custom PATH variable or ad-hoc
> scripts or aliases.
> If, in addition to that, Qt5 manages to install some symlinks or smart
> scripts to PREFIX/bin that's even better. :-)

The problem with having all binaries in ARCHDATADIR/bin is that some of those 
binaries are just plain duplication in multiarch, like designer, assistant, 
qdbus, qdbusviewer, etc. Please see my email in reply to Ossi and provide me 
with your suggestions on what to do.

> Also consider that if you decide for a split of the binaries, you run
> the risk that Qt6 will require a different split (some binary which is
> reusable between Qt4 and Qt5 might not be compatible with Qt6, or some
> Qt4-incompatible binary might work for both Qt5 and Qt6) and this might
> complicate the developer story later on.

We don't need to make Qt 5 forwards compatible with a non-existent Qt 6. We 
just need to make Qt 6 backwards compatible with Qt 5.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pending decisions on co-installation

[Thiago Macieira]

On quarta-feira, 31 de outubro de 2012 12.23.27, Oswald Buddenhagen wrote:
> > 3) library versioning (i.e., adding "5" to the library name)
>
> -1
>
> renaming is unnecessary:
> - there is no problem at all at run-time
> - the problem at build time is solved by -L flags. there is no need for
>   an unversioned symlink in /usr/lib.
> renaming is a bit disruptive:
> - projects not done with qmake need adjustment/ifdefs
>   - but then, they probably need adjustment anyway due to the libraries
> having been split, etc.

Ossi: let me ask you something then: do you want our make install to manage
both /usr/lib *and* /usr/lib/qt5/lib?

If so, we need to know about both build dirs and therefore we need --
prefix=/usr on installations.

If not, I am going to require you to write a script for distros installing
each Qt tarball so that they do the right thing for each library and it does
not hardcode anything.

My argument is that the split is necessary because we're being asked to manage
all of this. I'm also with Ján here that trying to override the default search
paths is troublesome. Some less sophisticated buildsystems might add -
L/usr/lib64 due to other dependencies saying that is necessary, then all of a
sudden the application will start linking to Qt 4.

(on OpenSUSE) $ mysql_config --libs
-L/usr/lib64 -lmysqlclient -lpthread -lz -lm -lrt -lssl -lcrypto -ldl

Mark my words: this is a recipe for disaster.

> the -archdatadir option as such does not hurt, but it introduces a
> backwards-incompatibility (projects which don't use it on a system which
> uses different dirs will fail to find the data). i'd prefer to postpone
> this to The Next Real Major Version ™.

The only thing that uses DataDir is qmake, to find its mkspecs. Also, quite
clearly QLibraryInfo is about Qt itself. Other libraries and applications have
no business using those paths. Therefore, I argue that:

1) they shouldn't store their files there
2) if they are using to read some Qt files, the only ones affected are the
mkspecs, which require quite an updated parser anyway.

> > 5) executable split between end-user applications and indirect tooling
> > [...]
>
> -2
>
> > This proposal has met with vehement opposition and I'd like to hear why.
>
> as others pointed out, the split is arbitrary, and - given your wrapper
> - just unnecessary.

Ok, then let's see what your proposal is:

All of our executables are installed to /usr/lib$suffix/qt5/bin. What else?

Please choose one of:
 a) we wrap all the executables there in /usr/bin
 b) we wrap only some of the executables there in /usr/bin (please include a
list of which ones)
 c) we wrap some executables in /usr/bin and we symlink others to /usr/bin
(please include a list of which ones on each group)
 d) we do nothing

If you choose any option of a to c, we require --prefix=/usr and modification to
the buildsystem. If you choose option d, then please provide the script or at
least very detailed instructions for distributions on how to populate
/usr/bin.

Also, do I understand correctly that you're suggesting that multiarch
distributions should have *both*:
/usr/lib/qt5//bin/assistant AND 
/usr/lib64/qt5/bin/assistant
/usr/lib/qt5//bin/linguist  AND 
/usr/lib64/qt5/bin/linguist
/usr/lib/qt5//bin/designer  AND 
/usr/lib64/qt5/bin/designer

If you're not suggesting that, then are you suggesting that those applications
should be symlinked directly to /usr/bin, instead of tool-wrapped (which
detects multiarch)? Are there any other tools that you suggest should be
symlinked?
--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Dependencies of Qt5

[Thiago Macieira]

On quarta-feira, 31 de outubro de 2012 10.28.12, Simon Hausmann wrote:
> > Simon: what's the difference between flex and win_flex? Note that there's
> > a
> > flex with msysgit, so if we used flex instead of win_flex, it would make
> > setups easier.
> 
> The issue comes from GnuWin32 having a version of flex that is too old for 
> Angle. In WebKit land we've told people to install the GNU tools from the 
> GnuWin32 distribution (gperf, etc.) and unfortunately the version there is 
> outdated. Hence the discovery of win_flex.
> 
> I suppose a better solution would be to have a real configure check for flex
> in  qtbase and see if the version in PATH is new enough. We can still try
> to use a copy of qt5.git/gnuwin32 as fallback if we can locate it.

What is the minimum required version?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pending decisions on co-installation

[Oswald Buddenhagen]

On Wed, Oct 31, 2012 at 01:26:09PM +0100, Jan Kundrát wrote:
> On 10/31/12 12:23, Oswald Buddenhagen wrote:
> > renaming is unnecessary:
> > - there is no problem at all at run-time
> > - the problem at build time is solved by -L flags. there is no need for
> >   an unversioned symlink in /usr/lib.
> 
> On RHEL6, this is how it looks right now:
> 
> kundratj@noe2 ~ $ locate /libQtCore.so
> /usr/lib64/libQtCore.so.4
> /usr/lib64/libQtCore.so.4.6
> /usr/lib64/libQtCore.so.4.6.2
> 
> If I remember correctly, it's rather hard to persuade the linker to
> ignore stuff below /usr/lib64 and use some other destination instead.
> 
there is no need to make it ignore anything, as -lQtCore would not find
any of the above files. the unversioned symlink would be found by virtue
of adding -L/usr/lib64/qt5/lib to the linker command line, and that
directory (which you get from qmake -query QT_INSTALL_LIBS) containing
said unversioned symlink. this really isn't rocket science ...
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pending decisions on co-installation

[Sune Vuorela]

On 2012-10-31, Poenitz Andre  wrote:
> This is not about "overriding someone". This is about ranking the user 
> experience of the majority of users higher than the convenience of a 
> handful of Linux distribution packagers - half which will do their own 
> renaming anyway, no matter what the official solution will look like.

I really think that if we (qt project) has to rely on us (packagers) to
do and get the renaming right then we (qt project) has failed.

And I still think that the majority of our (qt project *and*
distribution packagers) use Qt from distribution packages.

/Sune

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Request for a new playground project

[Jarkko Laitinen]

Hi,

I have been developing a cloud integration module for Qt. The working name
for the project is QCloud. It provides an API to do requests to Amazons S3
and Windows Azure. This has been my masters thesis project and it has been
done with consultation from Digia. The project is in that kind of a state
that it could be uploaded to playground. I am not sure what the project
should contain when it is uploaded to the playground, documentation is
almost done but tests are still incomplete. I will include a readme that
helps with the installation and the documentation should provide enough
information for the developers on how to use the module. I am happy
to answer more questions if there are any.

-B.Sc Jarkko Laitinen-
-Mathematical Information Technology-
-University of Jyväskylä-
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] MinGW-builds in CI system (Qt 5)

[Anttila Janne]

Koehne Kai wrote:

> Now that the big thing (CI system migration) is done, I'm wondering whether
> we can get also MinGW into the CI system for Qt 5? It's a Tier 1 platform, so
> it should really be part of the CI testing. I understand that in the past we
> didn't do it because the outdated gcc in Mingw caused quite some headache
> (crashed), but things have improved since then. It's also a somewhat slow
> platform (mingw32-make -j has still it's quirks because sometimes the debug
> and release rules touch the same file), but until we fixed that I could 
> imagine
> we run it e.g. without tests ...
> 
> The MinGW distribution we've tested best so far is MinGW-builds:
> http://sourceforge.net/projects/mingwbuilds
> 
> MinGW-builds is featuring both a 32 bit and 64 bit compiler package, and
> ideally we should test both.
> 

We are already aware about MinGW needs related to CI system: 
https://bugreports.qt-project.org/browse/QTQAINFRA-549.

However we are currently a bit limited on HW capacity, in practice we have
just half of the HW capacity what Nokia had earlier. Now that the migration
is completed, there are activities ongoing to pack and ship rest of the Brisbane
HW to Finland. Packing, air cargo, setup, OS installations etc will take some 
time, so I would assume that we have more HW capacity available in 
~1 month timeframe. 

As an intermediate step we are right now trying arrange some more HW capacity
from Digia internal cloud and other sources. However there are several 
different requests for that capacity: Windows 7 with MinGW, Windows 8 with 
MSDN 2012, Mac OSX 10.8, adding WebKit to CI system, etc, and there has been
also discussion to take "Branching for Qt 5 repositories" in use after 
Qt5 beta 2.

Since we are currently limited on capacity we cannot do all of these right now.
I'm afraid that MinGW CI support drops to that category and we need to wait
for HW from Brisbane to arrive...

--
Janne Anttila
Senior Architect - Digia, Qt
Visit us on: http://qt.digia.com 


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QML Profiler for Qt5

[Labs, Torsten]

Hi Christaan,

thx for the very good declaration. Our problem is that we want to implement an 
automatic performance test. So we would like to measure two things:

1. Page switch time (Switch from on QML Page to another random QML page. Each 
page has several QML Elements on it). We would like to know at which time is 
the page visible for the customer.

2. Page refresh time if we change values or elements on the page. Although 
there its important for us to get the time when the new values are visible for 
the customer on the page.

For both we need a trigger when the page is visible for the customer and 
completly painted.

Do you know how we could do that with Qt 5?

Thx

Torsten


With best regards,
Torsten Labs

Siemens AG
Industry Sector
Industry Automation Division
Industrial Automation Systems
Factory Automation
I IA AS FA WF FTH 2
Siemensstr. 2-4
90766 Fuerth, Germany
Tel.: +49 911 978-3682
mailto:torsten.l...@siemens.com

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; 
Managing Board: Peter Loescher, Chairman, President and Chief Executive 
Officer; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara 
Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Suess; 
Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin 
Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322



From: Christiaan Janssen [mailto:christiaan.jans...@digia.com]
Sent: Wednesday, October 31, 2012 11:00 AM
To: Labs, Torsten
Cc: development@qt-project.org
Subject: Re: [Development] QML Profiler for Qt5

Hello Torsten,

  the internal architecture of the rendering has changed significantly between 
QtQuick1 and QtQuick2, due to the fact that the second one is based on a scene 
graph.  In this second case, we don't have individual paint events to track, 
since the rendering is managed in a synchronous way by the scene graph.  What 
individual items do is set a "dirty" flag which will trigger a redraw on the 
next pass of the renderer.  In other words, we don't have strict "paint" events 
with a duration, in the same sense as we did in QtQuick1.  That's why the 
initial decision was to track the updates of the animation driver instead; a 
measurement of the framerate of the animations was considered to be significant 
when it comes to potential optimizations a developer would be interested in.

  That being said, there are plans to display more information about the 
internals of the renderer (basically, time it takes to parse the scenegraph 
within a frame, and time it takes to generate the related OpenGL commands).  
Unfortunately, that is still a work in progress.

  If you are performing that rotation with a RotationAnimation, NumberAnimation 
or PropertyAnimation, you should be able to see the frames in the profiler 
trace.  If you are only updating the related property with some sort of timer 
by using bindings or overwriting the value from JavaScript, you will only see 
the event related to the code that modifies said property in the bindings 
section or/and in the JavaScript tab of the profiler.

  best regards,
  Christiaan Janssen


On 10/30/2012 10:24 AM, Labs, Torsten wrote:
Hello Christiaan,

thx for the answere. So as i understood now QML Profiler does only show 
animation events an not initial paintings? For QtQuick1.0 it was working. Is it 
planned?

We have a roation of an arrow every 100ms and even there we can't see any paint 
events.

Greetings

Torsten


With best regards,
Torsten Labs

Siemens AG
Industry Sector
Industry Automation Division
mailto:torsten.l...@siemens.com

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; 
Managing Board: Peter Loescher, Chairman, President and Chief Executive 
Officer; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara 
Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Suess; 
Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin 
Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322




From: Christiaan Janssen [mailto:christiaan.jans...@digia.com]
Sent: Monday, October 29, 2012 4:38 PM
To: Labs, Torsten
Cc: development@qt-project.org
Subject: Re: [Development] QML Profiler for Qt5

Hello Torsten,
I took a look at the file you provided.  I didn't see anything wrong with it.  
It's just that you don't have any animation frame events.  Does you application 
have animations?  Elements like Flickable or Behaviour also use animations, 
those should show.  If not, that would explain why you don't see them in the 
trace.

The Qml profiler, when profiling Qt5 animations, shows the frame events for 
animations, but not paint events for static objects.

I hope this explanation helps.

Best regards,
Christiaan Janssen

On 10/29/2012 02:47 PM, ext Labs, Torsten wrote:
Hello,

i trie

Re: [Development] Pending decisions on co-installation

[Jan Kundrát]

On 10/31/12 12:23, Oswald Buddenhagen wrote:
> renaming is unnecessary:
> - there is no problem at all at run-time
> - the problem at build time is solved by -L flags. there is no need for
>   an unversioned symlink in /usr/lib.

On RHEL6, this is how it looks right now:

kundratj@noe2 ~ $ locate /libQtCore.so
/usr/lib64/libQtCore.so.4
/usr/lib64/libQtCore.so.4.6
/usr/lib64/libQtCore.so.4.6.2

kundratj@noe2 ~ $ rpm -qf /usr/lib64/libQtCore.so.4
qt-4.6.2-24.el6.x86_64

If I remember correctly, it's rather hard to persuade the linker to
ignore stuff below /usr/lib64 and use some other destination instead. I
tend to purge such unpleasant memories from my mind, though, so I cannot
provide much detail.

I suspect that RHEL6 would be on the top of the list of Linux
distributions to support.

> renaming is a bit disruptive:
> - projects not done with qmake need adjustment/ifdefs
>   - but then, they probably need adjustment anyway due to the
> libraries
> having been split, etc.

I can imagine that updating a few lines in a project's build system to
make it link against a different library name would be the smallest
obstacle of any porting process, especially compared to other changes
required. Again, I might be wrong.

Cheers,
Jan

-- 
Trojita, a fast e-mail client -- http://trojita.flaska.net/



signature.asc
Description: OpenPGP digital signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Proofreaders for changes from non-native English speakers

[Mitch Curtis]

I thought it'd be useful for non-native English speakers (or even native 
English speakers) who'd like proofreading done to know who they can add as 
reviewers. There is a list of people who are willing to do language reviews 
under the Approvers and Editors section here:

http://qt-project.org/wiki/Category:Developing_Qt::Documentation

I've also mentioned this under the Additional notes section here:

http://qt-project.org/wiki/Commit_Policy

If you are a Gerrit user, a native or fluent English speaker and would like to 
be listed as a proofreader, please add yourself to the list.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pending decisions on co-installation

[Oswald Buddenhagen]

this is just re-iterating stuff, but whatever.

On Tue, Oct 30, 2012 at 01:47:03PM -0700, Thiago Macieira wrote:
> 1) QML environment variables
>
+1

> 2) QML tool names
>
0

> 3) library versioning (i.e., adding "5" to the library name)
>
-1

renaming is unnecessary:
- there is no problem at all at run-time
- the problem at build time is solved by -L flags. there is no need for
  an unversioned symlink in /usr/lib.
renaming is a bit disruptive:
- projects not done with qmake need adjustment/ifdefs
  - but then, they probably need adjustment anyway due to the libraries
having been split, etc.

otoh, we probably should rename the .pc files. this does *not* imply
renaming the libraries, except that it's less work with qmake, and you
already have done it.

so not having definite arguments either side, i'd lean to the status
quo. but feel free to try making a strong case in favor of change.

> 4) new installation paths (besides the bin directory)
> The latest patch I've provided creates a grouping of all arch-dependent files 
> in ARCHDATADIR, with arch-independent files in DATADIR. That change, by 
> itself, 
> is innocuous since it doesn't produce any difference in installation.
> 
> The decision we need is on the defaults for those two directories. My 
> proposal 
> is to have ARCHDATADIR=LIBDIR/qt5 and DATADIR=PREFIX/share/qt5 on Unix build 
> that require make install *only*. Again, there are arguments for and against, 
> so let's hear them.
> 
-2

it's just pointless to change the defaults (because it's trivial for
distros to adjust the paths, and diversity does not hurt in any way),
and it's counterproductive to introduce inconsistency in the defaults
between installed and non-installed builds.

the -archdatadir option as such does not hurt, but it introduces a
backwards-incompatibility (projects which don't use it on a system which
uses different dirs will fail to find the data). i'd prefer to postpone
this to The Next Real Major Version ™.

> 5) executable split between end-user applications and indirect tooling
> [...]
>
-2

> This proposal has met with vehement opposition and I'd like to hear why.
> 
as others pointed out, the split is arbitrary, and - given your wrapper
- just unnecessary.

> Finally, I am not listing the separation of paths for QML 1 and 2, since I 
> have not heard opposition to that fact. If I'm wrong, do speak up.
> 
+2
the relavant patch is delayed only because of the dependency on 4.

regards
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pending decisions on co-installation

[Stephen Kelly]

On Wednesday, October 31, 2012 09:46:18 Alberto Mardegan wrote:
> Also consider that if you decide for a split of the binaries, you run 
> the risk that Qt6 will require a different split (some binary which is 
> reusable between Qt4 and Qt5 might not be compatible with Qt6, or some 
> Qt4-incompatible binary might work for both Qt5 and Qt6) and this might 
> complicate the developer story later on.

I think this is a good point. Any solution which is not guaranteed to work for 
Qt 6 is probably not a good enough solution.

Thanks,

-- 
Stephen Kelly  | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
** Qt Developer Conference: http://qtconference.kdab.com/ **

signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pending decisions on co-installation

[Koehne Kai]

> -Original Message-
> From: development-bounces+kai.koehne=digia@qt-project.org
> [mailto:development-bounces+kai.koehne=digia@qt-project.org] On
> Behalf Of Thiago Macieira
> [...]
> 2) QML tool names
> Kai raised the point that many of the QML 2 tools work for QML 1 too and
> maybe even for Qt 4's QML 1. We need confirmation on that as well as the
> willingness to keep them that way for one or two years at least. For the
> tools that work on both QML engines, we can drop the version number from
> their names.

qmlprofiler - works with Qt 4.8 target, Christiaan Janssen as QML Profiler 
maintainer agrees to further support it.
qmlmin - tried it successfully with some Qt 4.8 .qml files. I think this is a 
safe bet, since we just extended the .qml grammar in QtQuick2. CC'ed Roberto 
(the original author) anyway.
qmlscene - this potentially loads binary Qt plugins, therefore tied to Qt 
version
qmlplugindump - sole purpose is to load binary plugins. Highly tied to Qt 
version.
qmlbundle - New in QtQuick2, but it's unfortunately  completely undocumented 
[1]. Not sure whether it'll break with a QtQuick3.
qmltestrunner - New in QtQuick2. Not sure whether it makes sense to promise 
compatibility with a QtQuick3.

So, I think we can move qmlprofiler, qmlmin to user tools (available in default 
PATH) and keep their names. Regarding the naming, I think only the qmlscene and 
qmlviewer names really matter - that's the tools people call often, and that's 
why I think we should keep them also in a default PATH (disambiguating them 
from qt 4 qmlviewer by name). A quick poll in the office ended up with 
qml1viewer, qml2viewer as winner :)
 
[1]: Created https://bugreports.qt-project.org/browse/QTBUG-27783

My 2 cents,

Kai
 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pending decisions on co-installation

[Poenitz Andre]

Sune Vuorela:
> This is something that will happen to be done. and for the sake of
> documentation and support, please let it be consistant not only across
> distributions, but also across platforms so that documentations don't
> have to be
> if mac | upstream-provided-linux-builds {
>   run qmake
> } else if windows {
>   run qmake.exe
> } else if debian {
>   run qmake-qt5
> } elese if fedora {
>   run qmake5

Nobody was asking for that. 

The attempts at a solution were revolving so far around

 (a) providing a means to select a sandboxed Qt version
 (b) running qmake

(a) can be as much as "nothing" on all setups that only have a single
version of Qt around, or some other means to switch (like when using 
Creator, or whatever distributions consider "native" on their system), 
and (b) is obviously cross-platform.

> Yes. we need to do something. and if the 'something' is to ask Lars as
> chief maintainer to override Ossi, then we must do that.

This is not about "overriding someone". This is about ranking the user 
experience of the majority of users higher than the convenience of a 
handful of Linux distribution packagers - half which will do their own 
renaming anyway, no matter what the official solution will look like.

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pending decisions on co-installation

[Sune Vuorela]

On 2012-10-30, Thiago Macieira  wrote:
> 1) QML environment variables
> The variable for import paths has been versioned from QML_IMPORT_PATH to 
> QML2_IMPORT_PATH. But I have not changed any of the other variables. We need 
> a 
> decision from the team familiar with the engines and the meanings of those 
> variables to know which ones should be versioned too.
>
> They need to be versioned if having a value set in it applies to one QML 
> engine but has ill-effects for the other.

isn't 'not versioning this' a recipe for disaster for both end users of
applications and for developers of applications if we don't do something

>
> 2) QML tool names
> Kai raised the point that many of the QML 2 tools work for QML 1 too and 
> maybe 
> even for Qt 4's QML 1. We need confirmation on that as well as the 
> willingness 
> to keep them that way for one or two years at least. For the tools that work 
> on both QML engines, we can drop the version number from their names.

ack.

> 3) library versioning (i.e., adding "5" to the library name)
> I'd like to see a decision here, one way or the other. I've posted my 
> arguments in favour more than once and I know there are people who disagree. 
> So let's hear from them why they disagree so we can see if there's a 
> consensus[*]. I'll similarly post the arguments in favour and I'd appreciate 
> if other people who agree did the same.

I would really like to see a '5' added. that way, people can use distro
packages and develop for qt4 on the same installation as they develop
for qt5. And this is very much going to be a issue.
the /usr/lib/libQtCore.so symlink can only point to one place at a time.

Alternatively, distributions will do something like that, and maybe even
do it differently and if we ar ereal lucky even break the much-valued
binary compatibility between installations - assuming that one distro
does libQt5Core, another does libQtCore5 and some just does a libQtCore.
The only way to prevent this is that we as Qt project (as oppsode to we
as packagers) actually does it. Having distro-qt's binary compatible
with upstream qt and other qt's (modulo fuckups) is a advantage.

> 4) new installation paths (besides the bin directory)
> The latest patch I've provided creates a grouping of all arch-dependent files 
> in ARCHDATADIR, with arch-independent files in DATADIR. That change, by 
> itself, 
> is innocuous since it doesn't produce any difference in installation.
>
> The decision we need is on the defaults for those two directories. My 
> proposal 
> is to have ARCHDATADIR=LIBDIR/qt5 and DATADIR=PREFIX/share/qt5 on Unix build 
> that require make install *only*. Again, there are arguments for and against, 
> so let's hear them.

For me, ensuring a 100% correct split between arch-dep and arch-indep
files isn't the most important issue, given that we, at a bit of a disk
space cost can put files where we are in doubt

> 5) executable split between end-user applications and indirect tooling
> The most controversial proposal so far is to split the binaries into two 
> groups: one that gets installed to PREFIX/bin, containing the executables for 
> applications run directly by the user and which retain backwards 
> compatibility 
> of purpose, and one that gets installed to ARCHDATADIR/bin that contains the 
> tools that users generally do not run directly and which are specific to a 
> particular build of Qt. Please note that, in the current implementation, like 
> in #4 above, most people on this list will not see a change, as it applies to 
> Unix builds that require make install *only*.
>
> This proposal has met with vehement opposition and I'd like to hear why.

This is something that will happen to be done. and for the sake of
documentation and support, please let it be consistant not only across
distributions, but also across platforms so that documentations don't
have to be 
if mac | upstream-provided-linux-builds {
  run qmake
} else if windows {
  run qmake.exe
} else if debian {
  run qmake-qt5
} elese if fedora {
  run qmake5
}

Yes. we need to do something. and if the 'something' is to ask Lars as 
chief maintainer to override Ossi, then we must do that.

/Sune

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QML Profiler for Qt5

[Christiaan Janssen]

Hello Torsten,

  the internal architecture of the rendering has changed significantly 
between QtQuick1 and QtQuick2, due to the fact that the second one is 
based on a scene graph.  In this second case, we don't have individual 
paint events to track, since the rendering is managed in a synchronous 
way by the scene graph.  What individual items do is set a "dirty" flag 
which will trigger a redraw on the next pass of the renderer.  In other 
words, we don't have strict "paint" events with a duration, in the same 
sense as we did in QtQuick1.  That's why the initial decision was to 
track the updates of the animation driver instead; a measurement of the 
framerate of the animations was considered to be significant when it 
comes to potential optimizations a developer would be interested in.


  That being said, there are plans to display more information about 
the internals of the renderer (basically, time it takes to parse the 
scenegraph within a frame, and time it takes to generate the related 
OpenGL commands).  Unfortunately, that is still a work in progress.


  If you are performing that rotation with a RotationAnimation, 
NumberAnimation or PropertyAnimation, you should be able to see the 
frames in the profiler trace.  If you are only updating the related 
property with some sort of timer by using bindings or overwriting the 
value from JavaScript, you will only see the event related to the code 
that modifies said property in the bindings section or/and in the 
JavaScript tab of the profiler.


  best regards,
  Christiaan Janssen


On 10/30/2012 10:24 AM, Labs, Torsten wrote:

Hello Christiaan,
thx for the answere. So as i understood now QML Profiler does only 
show animation events an not initial paintings? For QtQuick1.0 it was 
working. Is it planned?
We have a roation of an arrow every 100ms and even there we can't see 
any paint events.

Greetings
Torsten

With best regards,
Torsten Labs

Siemens AG
Industry Sector
Industry Automation Division
mailto:torsten.l...@siemens.com

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard 
Cromme; Managing Board: Peter Loescher, Chairman, President and Chief 
Executive Officer; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe 
Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. 
Solmssen, Michael Suess; Registered offices: Berlin and Munich, 
Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, 
Munich, HRB 6684; WEEE-Reg.-No. DE 23691322




*From:* Christiaan Janssen [mailto:christiaan.jans...@digia.com]
*Sent:* Monday, October 29, 2012 4:38 PM
*To:* Labs, Torsten
*Cc:* development@qt-project.org
*Subject:* Re: [Development] QML Profiler for Qt5

Hello Torsten,
I took a look at the file you provided.  I didn't see anything wrong 
with it.  It's just that you don't have any animation frame events.  
Does you application have animations?  Elements like Flickable or 
Behaviour also use animations, those should show.  If not, that would 
explain why you don't see them in the trace.


The Qml profiler, when profiling Qt5 animations, shows the frame 
events for animations, but not paint events for static objects.


I hope this explanation helps.

Best regards,
Christiaan Janssen

On 10/29/2012 02:47 PM, ext Labs, Torsten wrote:

Hello,
i tried to connect a QML Profiler from Qt5 with my Qt5 project and 
unfortunaly i can not see any paint events. The QML Profiler connects 
remote to a Arm9 board. Do i have to add something else or is it just 
not implemented yet in Qt5 Beta1? Attached you can see a recorded trace.

Greetings

With best regards,
Torsten Labs

Siemens AG
Industry Sector
Industry Automation Division
Industrial Automation Systems
Factory Automation
mailto:torsten.l...@siemens.com

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: 
Gerhard Cromme; Managing Board: Peter Loescher, Chairman, President 
and Chief Executive Officer; Roland Busch, Brigitte Ederer, Klaus 
Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried 
Russwurm, Peter Y. Solmssen, Michael Suess; Registered offices: 
Berlin and Munich, Germany; Commercial registries: Berlin 
Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322




___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



--
Christiaan Janssen
Senior Software Engineer
Digia, Qt

Digia Germany GmbH
Rudower Chausse 13, 12489 D-Berlin
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B,
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Email:christiaan.jans...@digia.com  
Tel: +49 30 63 92 32 55
http://qt.digia.com  
Qt Blog:http://blog.qt.digia.com/
Qt Facebook:www.facebook.com/qtcommercial  
Qt Twitter:www.twitter.com/qtcommercial  


Digia Germany is a group company of Digia Plc,
Valimotie 21, FI-00380 Hel

Re: [Development] Dependencies of Qt5

[Simon Hausmann]

On Tuesday, October 30, 2012 07:39:34 AM Thiago Macieira wrote:
> On terça-feira, 30 de outubro de 2012 13.38.03, Hausmann Simon wrote:
> > Note that qt5.git also contains binaries of bison and win_flex needed by
> > WebKit. If qtwebkit is built as part of qt5.git then those binaries will
> > be
> > used automatically.
> 
> ANGLE requires bison and flex.
> 
> Simon: what's the difference between flex and win_flex? Note that there's a
> flex with msysgit, so if we used flex instead of win_flex, it would make
> setups easier.

The issue comes from GnuWin32 having a version of flex that is too old for 
Angle. In WebKit land we've told people to install the GNU tools from the 
GnuWin32 distribution (gperf, etc.) and unfortunately the version there is 
outdated. Hence the discovery of win_flex.

I suppose a better solution would be to have a real configure check for flex in 
qtbase and see if the version in PATH is new enough. We can still try to use a 
copy of qt5.git/gnuwin32 as fallback if we can locate it.


Simon
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Status of WP8 port

[Pau Garcia i Quiles]

Hello,

Microsoft has released the Windows Phone 8.0 SDK with native support.

http://blogs.windows.com/windows_phone/b/wpdev/archive/2012/10/30/announcing-the-new-windows-phone-8-developer-platform.aspx

https://dev.windowsphone.com/en-us/downloadsdk


What's the status of Qt 5 on WP8? Last I remember, a feasibility study
was being carried on. What was the outcome?

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] MinGW-builds in CI system (Qt 5)

[Koehne Kai]

Hi Janne and Samuli,

Now that the big thing (CI system migration) is done, I'm wondering whether we 
can get also MinGW into the CI system for Qt 5? It's a Tier 1 platform, so it 
should really be part of the CI testing. I understand that in the past we 
didn't do it because the outdated gcc in Mingw caused quite some headache 
(crashed), but things have improved since then. It's also a somewhat slow 
platform (mingw32-make -j has still it's quirks because sometimes the debug and 
release rules touch the same file), but until we fixed that I could imagine we 
run it e.g. without tests ...

The MinGW distribution we've tested best so far is MinGW-builds: 
http://sourceforge.net/projects/mingwbuilds

MinGW-builds is featuring both a 32 bit and 64 bit compiler package, and 
ideally we should test both.
 
Regards

Kai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pending decisions on co-installation

[Alberto Mardegan]

On 10/31/2012 01:06 AM, Thiago Macieira wrote:
> In any case, what's the problem with making a subjective decision? Clearly the
> applications need to be split in two groups, so why shouldn't the Qt Project
> make its recommendation to the downstreams?

I would like that all binaries are installed in ARCHDATADIR/bin, so that 
they can be all easily accessed with a custom PATH variable or ad-hoc 
scripts or aliases.
If, in addition to that, Qt5 manages to install some symlinks or smart 
scripts to PREFIX/bin that's even better. :-)

Also consider that if you decide for a split of the binaries, you run 
the risk that Qt6 will require a different split (some binary which is 
reusable between Qt4 and Qt5 might not be compatible with Qt6, or some 
Qt4-incompatible binary might work for both Qt5 and Qt6) and this might 
complicate the developer story later on.

If we could say that everything is guaranteed to be in (at least) 
ARCHDATADIR/bin, that's some sure information we (or distros) can use to 
build better/custom tools on top of that.

Ciao,
   Alberto
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development