From Yves.Bailly at verosoftware.com Fri Aug 1 09:06:06 2014
From: Yves.Bailly at verosoftware.com (Yves Bailly)
Date: Fri, 1 Aug 2014 06:06:06 +0000
Subject: [Development] QOpenGLWidget vs. QGLWidget
In-Reply-To:
References: <53DA26DB.3030805@verosoftware.com>
Message-ID: <53DB2E4C.7040904@verosoftware.com>
On 31/07/2014 20:03, Agocs Laszlo wrote:
> Yes, setViewport() will continue to work with QOpenGLWidget too.
Great! :-)
> Note that all this does not mean existing code has to migrate away from QGLWidget.
> It is not going to disappear. If it works, just keep using it.
Fine, however QGLWidget's status moving to "deprecated" is the first step
on the road to "obsolete", then sooner or later "removed"... So I guess
new codes should use QOpenGLWidget, while old ones should migrate little
by little.
Is there already some doc somewhere, describing the differences between
QGLWidget and QOpenGLWidget? not only the API, also the internals maybe.
Regards,
--
/- Yves Bailly - Software developer -\
\- Sescoi R&D - http://www.sescoi.fr -/
"The possible is done. The impossible is being done. For miracles,
thanks to allow a little delay."
From Yves.Bailly at verosoftware.com Fri Aug 1 09:06:06 2014
From: Yves.Bailly at verosoftware.com (Yves Bailly)
Date: Fri, 1 Aug 2014 06:06:06 +0000
Subject: [Development] QOpenGLWidget vs. QGLWidget
In-Reply-To:
References: <53DA26DB.3030805@verosoftware.com>
Message-ID: <53DB2E4C.7040904@verosoftware.com>
On 31/07/2014 20:03, Agocs Laszlo wrote:
> Yes, setViewport() will continue to work with QOpenGLWidget too.
Great! :-)
> Note that all this does not mean existing code has to migrate away from QGLWidget.
> It is not going to disappear. If it works, just keep using it.
Fine, however QGLWidget's status moving to "deprecated" is the first step
on the road to "obsolete", then sooner or later "removed"... So I guess
new codes should use QOpenGLWidget, while old ones should migrate little
by little.
Is there already some doc somewhere, describing the differences between
QGLWidget and QOpenGLWidget? not only the API, also the internals maybe.
Regards,
--
/- Yves Bailly - Software developer -\
\- Sescoi R&D - http://www.sescoi.fr -/
"The possible is done. The impossible is being done. For miracles,
thanks to allow a little delay."
From nilesh.kokane at mindastoneridge.com Fri Aug 1 12:19:55 2014
From: nilesh.kokane at mindastoneridge.com (Nilesh Kokane)
Date: Fri, 1 Aug 2014 14:49:55 +0530
Subject: [Development] bitbake meta-toolchain error
Message-ID:
Hello,
I followed
http://wiki.wandboard.org/index.php/Building_Qt5_using_yocto_on_Wandboard
(newly added)
The DISTRO_FEATURES_remove = "x11 wayland" is removed from the local.conf
And after giving the bitbake core-image-minimal I'm logged with the errors
as posted on pastebin http://pastebin.com/hsMhT9f8
ERROR: Function failed: do_compile (log file is located at
/home/minda/bin/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/qtbase/5.2.1-r0/temp/log.do_compile.28369)
ERROR: Logfile of failure stored in:
/home/minda/bin/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/qtbase/5.2.1-r0/temp/log.do_compile.28369
ERROR: Task 655
(/home/minda/bin/fsl-community-bsp/sources/meta-qt5/recipes-qt/qt5/
qtbase_5.2.1.bb, do_compile) failed with exit code '1'
can anyone suggest.
--
“The contents of this e-mail message and any attachments are confidential
and are intended solely for addressee. The information may also be legally
privileged. This transmission is sent in trust, for the sole purpose of
delivery to the intended recipient. If you have received this transmission
in error, any use, reproduction or dissemination of this transmission is
strictly prohibited. If you are not the intended recipient, please
immediately notify the sender by reply e-mail or phone and delete this
message and its attachments, if any.”
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From nilesh.kokane at mindastoneridge.com Fri Aug 1 12:19:55 2014
From: nilesh.kokane at mindastoneridge.com (Nilesh Kokane)
Date: Fri, 1 Aug 2014 14:49:55 +0530
Subject: [Development] bitbake meta-toolchain error
Message-ID:
Hello,
I followed
http://wiki.wandboard.org/index.php/Building_Qt5_using_yocto_on_Wandboard
(newly added)
The DISTRO_FEATURES_remove = "x11 wayland" is removed from the local.conf
And after giving the bitbake core-image-minimal I'm logged with the errors
as posted on pastebin http://pastebin.com/hsMhT9f8
ERROR: Function failed: do_compile (log file is located at
/home/minda/bin/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/qtbase/5.2.1-r0/temp/log.do_compile.28369)
ERROR: Logfile of failure stored in:
/home/minda/bin/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/qtbase/5.2.1-r0/temp/log.do_compile.28369
ERROR: Task 655
(/home/minda/bin/fsl-community-bsp/sources/meta-qt5/recipes-qt/qt5/
qtbase_5.2.1.bb, do_compile) failed with exit code '1'
can anyone suggest.
--
“The contents of this e-mail message and any attachments are confidential
and are intended solely for addressee. The information may also be legally
privileged. This transmission is sent in trust, for the sole purpose of
delivery to the intended recipient. If you have received this transmission
in error, any use, reproduction or dissemination of this transmission is
strictly prohibited. If you are not the intended recipient, please
immediately notify the sender by reply e-mail or phone and delete this
message and its attachments, if any.”
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From sumedha.widyadharma at basyskom.com Fri Aug 1 17:45:16 2014
From: sumedha.widyadharma at basyskom.com (Sumedha Widyadharma)
Date: Fri, 01 Aug 2014 16:45:16 +0200
Subject: [Development] Relative paths in EXAMPLE_FILES in .pro files
Message-ID: <53DBA7FC.5070600@basyskom.com>
Hi,
This seems to be forbidden in a .pro file:
EXAMPLE_FILES += ../some/file
what is the rationale behind not allowing this?
It is silently dropped, you have to enable CONFIG+=check_examples to get
a notice about this. Why is that?
Shouldn't it always warn the user?
Regards,
Sumedha Widyadharma
--
Sumedha Widyadharma
System Integrator
basysKom GmbH
Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany
Tel : +49 6151 870 589 128 | Fax: +49 6151 870 589 199
sumedha.widyadharma at basyskom.com | www.basyskom.com
Handelsregister: Darmstadt HRB 9352
Geschäftsführung: Eva Brucherseifer, Heike Ziegler
From sumedha.widyadharma at basyskom.com Fri Aug 1 17:45:16 2014
From: sumedha.widyadharma at basyskom.com (Sumedha Widyadharma)
Date: Fri, 01 Aug 2014 16:45:16 +0200
Subject: [Development] Relative paths in EXAMPLE_FILES in .pro files
Message-ID: <53DBA7FC.5070600@basyskom.com>
Hi,
This seems to be forbidden in a .pro file:
EXAMPLE_FILES += ../some/file
what is the rationale behind not allowing this?
It is silently dropped, you have to enable CONFIG+=check_examples to get
a notice about this. Why is that?
Shouldn't it always warn the user?
Regards,
Sumedha Widyadharma
--
Sumedha Widyadharma
System Integrator
basysKom GmbH
Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany
Tel : +49 6151 870 589 128 | Fax: +49 6151 870 589 199
sumedha.widyadharma at basyskom.com | www.basyskom.com
Handelsregister: Darmstadt HRB 9352
Geschäftsführung: Eva Brucherseifer, Heike Ziegler
From ono at java.pl Fri Aug 1 18:13:43 2014
From: ono at java.pl (Adam Strzelecki)
Date: Fri, 1 Aug 2014 17:13:43 +0200
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
Message-ID:
Hello,
Since 5.4 feature freeze is going to happen soon, I want to escalate long standing problem described in QTBUG-31814.
Long story short, Qt is using some nasty install prefix padding and dylib rewrite (via install_name_tool) during Qt SDK install to handle user defined Qt SDK frameworks placement. This might be OK if we were in 2005 using OSX 10.4, but since 10.5 there is @rpath that makes whole process far less complicated.
Therefore there is absolutely no need for:
(1) MAKE_INSTALL_PADDING in qtsdk/packaging-tools/build_wrapper.py anyway dylibs are padded with -headerpad_max_install_names
(2) no need for MacReplaceInstallNamesOperation::relocateBinary(..) in installer-framework
(3) no need for similar relocation in macqtdeploy script, this would be especially useful in future when OSX uses ZFS's COW (no idea if HFS does already COW at block level when copying)
All we need to do is build all Qt dylibs with install_name = @rpath/pathrelative_to_lib_folder/some.dylib and make sure qmake adds following linker flags to all apps linking to Qt:
-Wl,-rpath, at loader_path/../Frameworks
-Wl,-rpath, at executable_path/../Frameworks
-Wl,-rpath,/absolute/path/to/dev/Qt/Frameworks
Then macdeployqt is just about removing last rpath from binary, leaving only these relative. No need to touch ever libraries once they are built.
This also makes whole SDK process installation pure copy process.
I am willing to help but this has to be changed in several projects qtsdk, installer-framework, qtbase (Qmake) in order to make it work.
Here is proposal for change in Qmake:
(1) adding QMAKE_RPATHPREFIX variable specyfying list of path prefixes that will be replaced by @rpath when linking OSX library, by default this will contain Qt SDK lib/ dir
(2) adding @rpath replacement in UnixMakefileGenerator::init2() before:
project->values("QMAKE_LFLAGS_SONAME").first() += escapeFilePath(soname);
Where prefix from QMAKE_RPATHPREFIX found in soname is replaced by "@rpath"
Once this is done qtbase Qmake project should define QMAKE_RPATHPREFIX to be Qt SDK install_prefix/lib during build process.
WDYT?
Regards,
--
Adam Strzelecki
From ono at java.pl Fri Aug 1 18:13:43 2014
From: ono at java.pl (Adam Strzelecki)
Date: Fri, 1 Aug 2014 17:13:43 +0200
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
Message-ID:
Hello,
Since 5.4 feature freeze is going to happen soon, I want to escalate long standing problem described in QTBUG-31814.
Long story short, Qt is using some nasty install prefix padding and dylib rewrite (via install_name_tool) during Qt SDK install to handle user defined Qt SDK frameworks placement. This might be OK if we were in 2005 using OSX 10.4, but since 10.5 there is @rpath that makes whole process far less complicated.
Therefore there is absolutely no need for:
(1) MAKE_INSTALL_PADDING in qtsdk/packaging-tools/build_wrapper.py anyway dylibs are padded with -headerpad_max_install_names
(2) no need for MacReplaceInstallNamesOperation::relocateBinary(..) in installer-framework
(3) no need for similar relocation in macqtdeploy script, this would be especially useful in future when OSX uses ZFS's COW (no idea if HFS does already COW at block level when copying)
All we need to do is build all Qt dylibs with install_name = @rpath/pathrelative_to_lib_folder/some.dylib and make sure qmake adds following linker flags to all apps linking to Qt:
-Wl,-rpath, at loader_path/../Frameworks
-Wl,-rpath, at executable_path/../Frameworks
-Wl,-rpath,/absolute/path/to/dev/Qt/Frameworks
Then macdeployqt is just about removing last rpath from binary, leaving only these relative. No need to touch ever libraries once they are built.
This also makes whole SDK process installation pure copy process.
I am willing to help but this has to be changed in several projects qtsdk, installer-framework, qtbase (Qmake) in order to make it work.
Here is proposal for change in Qmake:
(1) adding QMAKE_RPATHPREFIX variable specyfying list of path prefixes that will be replaced by @rpath when linking OSX library, by default this will contain Qt SDK lib/ dir
(2) adding @rpath replacement in UnixMakefileGenerator::init2() before:
project->values("QMAKE_LFLAGS_SONAME").first() += escapeFilePath(soname);
Where prefix from QMAKE_RPATHPREFIX found in soname is replaced by "@rpath"
Once this is done qtbase Qmake project should define QMAKE_RPATHPREFIX to be Qt SDK install_prefix/lib during build process.
WDYT?
Regards,
--
Adam Strzelecki
From jake.petroules at petroules.com Fri Aug 1 21:24:03 2014
From: jake.petroules at petroules.com (Jake Petroules)
Date: Fri, 1 Aug 2014 14:24:03 -0400
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To:
References:
Message-ID: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
On 2014-08-01, at 11:13 AM, Adam Strzelecki wrote:
> Hello,
>
> Since 5.4 feature freeze is going to happen soon, I want to escalate long standing problem described in QTBUG-31814.
>
> Long story short, Qt is using some nasty install prefix padding and dylib rewrite (via install_name_tool) during Qt SDK install to handle user defined Qt SDK frameworks placement. This might be OK if we were in 2005 using OSX 10.4, but since 10.5 there is @rpath that makes whole process far less complicated.
Yes, this is something that desperately needs to get done!
> Therefore there is absolutely no need for:
>
> (1) MAKE_INSTALL_PADDING in qtsdk/packaging-tools/build_wrapper.py anyway dylibs are padded with -headerpad_max_install_names
>
> (2) no need for MacReplaceInstallNamesOperation::relocateBinary(..) in installer-framework
>
> (3) no need for similar relocation in macqtdeploy script, this would be especially useful in future when OSX uses ZFS's COW (no idea if HFS does already COW at block level when copying)
>
> All we need to do is build all Qt dylibs with install_name = @rpath/pathrelative_to_lib_folder/some.dylib and make sure qmake adds following linker flags to all apps linking to Qt:
Just @rpath/QtModuleName.framework/Versions/A/QtModuleName and @rpath/qtsomethingorother.dylib
> -Wl,-rpath, at loader_path/../Frameworks
> -Wl,-rpath, at executable_path/../Frameworks
> -Wl,-rpath,/absolute/path/to/dev/Qt/Frameworks
>
> Then macdeployqt is just about removing last rpath from binary, leaving only these relative. No need to touch ever libraries once they are built.
No - don't include the last one. macdeployqt (nor any other tool) should NOT modify the binaries at all (modifying is bad for codesigning too). This is why we have DYLD_LIBRARY_PATH (see below).
> This also makes whole SDK process installation pure copy process.
>
> I am willing to help but this has to be changed in several projects qtsdk, installer-framework, qtbase (Qmake) in order to make it work.
I've also wanted to work on this for a while but my time is limited right now. I can definitely help with reviews though.
> Here is proposal for change in Qmake:
>
> (1) adding QMAKE_RPATHPREFIX variable specyfying list of path prefixes that will be replaced by @rpath when linking OSX library, by default this will contain Qt SDK lib/ dir
>
> (2) adding @rpath replacement in UnixMakefileGenerator::init2() before:
>
> project->values("QMAKE_LFLAGS_SONAME").first() += escapeFilePath(soname);
>
> Where prefix from QMAKE_RPATHPREFIX found in soname is replaced by "@rpath"
No, QMAKE_INSTALLNAMEPREFIX, which is set to "@rpath" (as opposed to an absolute path as is done currently).
> Once this is done qtbase Qmake project should define QMAKE_RPATHPREFIX to be Qt SDK install_prefix/lib during build process.
No replacement needs to be done. When building a Qt library, its install name is set at build time to @rpath/QtModuleName.framework/Versions/X/QtModuleName or @rpath/qtsomethingorother.dylib, there's no path to replace. When a consumer links to that library, it sets *its own* runpath search path to an array of paths appropriate for that binary (such as @loader_path/../Frameworks and @executable_path/../Frameworks). Absolute paths only start mattering at load time, not build time.
So, to summarize: the linker flags to build QtCore would be:
ld [...] -install_name @rpath/QtCore.framework/Versions/A/QtCore -rpath @loader_path/../Frameworks -rpath @executable_path/../Frameworks /Qt/clang_64/Frameworks/QtCore.framework/Versions/A/QtCore
and the linker flags to OurCoolApp which links to QtCore...
ld [...] -F/Qt/clang_64/Frameworks -framework QtCore -rpath @loader_path/../Frameworks -rpath @executable_path/../Frameworks /apps/MyApp.app/Contents/MacOS/MyApp
When we link to QtCore with -framework QtCore, the -install_name argument value we used to build QtCore gets embedded into OurCoolApp as the path we link against (see `otool -L OurCoolApp`). Then when we run OurCoolApp and try to load QtCore, the @rpath in QtCore's install name gets replaced by @executable_path/../Frameworks and @loader_path/../Frameworks, thus the runpath search path is resolved to @loader_path/../Frameworks/QtCore.framework/Versions/A/QtCore and @executable_path/../Frameworks/QtCore.framework/Versions/A/QtCore, which are then both resolved to /apps/MyApp.app/Contents/MacOS/../Frameworks/QtCore.framework/Versions/A/QtCore, thus /apps/MyApp.app/Contents/Frameworks/QtCore.framework/Versions/A/QtCore
No file exists at this path yet because we haven't copied it to our app bundle. So in development mode, Qt Creator, qbs, etc., would set an appropriate DYLD_LIBRARY_PATH to augment the existing runpath search paths (here's why we don't need your third absolute path as mentioned above). Like so:
export QT_INSTALL_LIBS=$(qmake -query QT_INSTALL_LIBS)
export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$QT_INSTALL_LIBS
/apps/MyApp.app/Contents/MacOS/MyApp
Thus when loading QtCore.framework, resolving [@loader_path/../Frameworks, @executable_path/../Frameworks, /Qt/clang_64/Frameworks] to [/apps/MyApp.app/Contents/Frameworks/QtCore.framework/Versions/A/QtCore, /Qt/clang_64/Frameworks/QtCore.framework/Versions/A/QtCore]
QtCore is not found at the first path, but is found at the second, and we load it. When we deploy, we run macdeployqt and QtCore is found at the first search path instead. Perfect harmony. :)
What might be good, too, is a QMAKE_EMBEDDED_FRAMEWORKS or somesuch which copies the Qt frameworks into the application bundle at build time (though you'd still set DYLD_LIBRARY_PATH because not everyone would necessarily use QMAKE_EMBEDDED_FRAMEWORKS). No reason to postpone that step to macdeployqt; this is how the native Apple tools work anyways. Ossi will disagree with me here and say that anything to do with creating bundle structures is a deployment step only, though. :)
Also, I'd add @executable_path/../Libraries and @loader_path/../Libraries to the search path as well. While less commonly known/used (and found in at least some official Apple documentation), some people do like to put frameworks in $CONTENTS_FOLDER_PATH/Frameworks and dylibs in $CONTENTS_FOLDER_PATH/Libraries.
>
> WDYT?
>
> Regards,
> --
> Adam Strzelecki
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
QLibraryInfo::location / qt.conf and such will need to be looked at as well to properly support an @rpath build of Qt. Thiago knows more about this.
--
Jake Petroules - jake.petroules at petroules.com
Chief Technology Officer - Petroules Corporation
From jake.petroules at petroules.com Fri Aug 1 21:24:03 2014
From: jake.petroules at petroules.com (Jake Petroules)
Date: Fri, 1 Aug 2014 14:24:03 -0400
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To:
References:
Message-ID: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
On 2014-08-01, at 11:13 AM, Adam Strzelecki wrote:
> Hello,
>
> Since 5.4 feature freeze is going to happen soon, I want to escalate long standing problem described in QTBUG-31814.
>
> Long story short, Qt is using some nasty install prefix padding and dylib rewrite (via install_name_tool) during Qt SDK install to handle user defined Qt SDK frameworks placement. This might be OK if we were in 2005 using OSX 10.4, but since 10.5 there is @rpath that makes whole process far less complicated.
Yes, this is something that desperately needs to get done!
> Therefore there is absolutely no need for:
>
> (1) MAKE_INSTALL_PADDING in qtsdk/packaging-tools/build_wrapper.py anyway dylibs are padded with -headerpad_max_install_names
>
> (2) no need for MacReplaceInstallNamesOperation::relocateBinary(..) in installer-framework
>
> (3) no need for similar relocation in macqtdeploy script, this would be especially useful in future when OSX uses ZFS's COW (no idea if HFS does already COW at block level when copying)
>
> All we need to do is build all Qt dylibs with install_name = @rpath/pathrelative_to_lib_folder/some.dylib and make sure qmake adds following linker flags to all apps linking to Qt:
Just @rpath/QtModuleName.framework/Versions/A/QtModuleName and @rpath/qtsomethingorother.dylib
> -Wl,-rpath, at loader_path/../Frameworks
> -Wl,-rpath, at executable_path/../Frameworks
> -Wl,-rpath,/absolute/path/to/dev/Qt/Frameworks
>
> Then macdeployqt is just about removing last rpath from binary, leaving only these relative. No need to touch ever libraries once they are built.
No - don't include the last one. macdeployqt (nor any other tool) should NOT modify the binaries at all (modifying is bad for codesigning too). This is why we have DYLD_LIBRARY_PATH (see below).
> This also makes whole SDK process installation pure copy process.
>
> I am willing to help but this has to be changed in several projects qtsdk, installer-framework, qtbase (Qmake) in order to make it work.
I've also wanted to work on this for a while but my time is limited right now. I can definitely help with reviews though.
> Here is proposal for change in Qmake:
>
> (1) adding QMAKE_RPATHPREFIX variable specyfying list of path prefixes that will be replaced by @rpath when linking OSX library, by default this will contain Qt SDK lib/ dir
>
> (2) adding @rpath replacement in UnixMakefileGenerator::init2() before:
>
> project->values("QMAKE_LFLAGS_SONAME").first() += escapeFilePath(soname);
>
> Where prefix from QMAKE_RPATHPREFIX found in soname is replaced by "@rpath"
No, QMAKE_INSTALLNAMEPREFIX, which is set to "@rpath" (as opposed to an absolute path as is done currently).
> Once this is done qtbase Qmake project should define QMAKE_RPATHPREFIX to be Qt SDK install_prefix/lib during build process.
No replacement needs to be done. When building a Qt library, its install name is set at build time to @rpath/QtModuleName.framework/Versions/X/QtModuleName or @rpath/qtsomethingorother.dylib, there's no path to replace. When a consumer links to that library, it sets *its own* runpath search path to an array of paths appropriate for that binary (such as @loader_path/../Frameworks and @executable_path/../Frameworks). Absolute paths only start mattering at load time, not build time.
So, to summarize: the linker flags to build QtCore would be:
ld [...] -install_name @rpath/QtCore.framework/Versions/A/QtCore -rpath @loader_path/../Frameworks -rpath @executable_path/../Frameworks /Qt/clang_64/Frameworks/QtCore.framework/Versions/A/QtCore
and the linker flags to OurCoolApp which links to QtCore...
ld [...] -F/Qt/clang_64/Frameworks -framework QtCore -rpath @loader_path/../Frameworks -rpath @executable_path/../Frameworks /apps/MyApp.app/Contents/MacOS/MyApp
When we link to QtCore with -framework QtCore, the -install_name argument value we used to build QtCore gets embedded into OurCoolApp as the path we link against (see `otool -L OurCoolApp`). Then when we run OurCoolApp and try to load QtCore, the @rpath in QtCore's install name gets replaced by @executable_path/../Frameworks and @loader_path/../Frameworks, thus the runpath search path is resolved to @loader_path/../Frameworks/QtCore.framework/Versions/A/QtCore and @executable_path/../Frameworks/QtCore.framework/Versions/A/QtCore, which are then both resolved to /apps/MyApp.app/Contents/MacOS/../Frameworks/QtCore.framework/Versions/A/QtCore, thus /apps/MyApp.app/Contents/Frameworks/QtCore.framework/Versions/A/QtCore
No file exists at this path yet because we haven't copied it to our app bundle. So in development mode, Qt Creator, qbs, etc., would set an appropriate DYLD_LIBRARY_PATH to augment the existing runpath search paths (here's why we don't need your third absolute path as mentioned above). Like so:
export QT_INSTALL_LIBS=$(qmake -query QT_INSTALL_LIBS)
export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$QT_INSTALL_LIBS
/apps/MyApp.app/Contents/MacOS/MyApp
Thus when loading QtCore.framework, resolving [@loader_path/../Frameworks, @executable_path/../Frameworks, /Qt/clang_64/Frameworks] to [/apps/MyApp.app/Contents/Frameworks/QtCore.framework/Versions/A/QtCore, /Qt/clang_64/Frameworks/QtCore.framework/Versions/A/QtCore]
QtCore is not found at the first path, but is found at the second, and we load it. When we deploy, we run macdeployqt and QtCore is found at the first search path instead. Perfect harmony. :)
What might be good, too, is a QMAKE_EMBEDDED_FRAMEWORKS or somesuch which copies the Qt frameworks into the application bundle at build time (though you'd still set DYLD_LIBRARY_PATH because not everyone would necessarily use QMAKE_EMBEDDED_FRAMEWORKS). No reason to postpone that step to macdeployqt; this is how the native Apple tools work anyways. Ossi will disagree with me here and say that anything to do with creating bundle structures is a deployment step only, though. :)
Also, I'd add @executable_path/../Libraries and @loader_path/../Libraries to the search path as well. While less commonly known/used (and found in at least some official Apple documentation), some people do like to put frameworks in $CONTENTS_FOLDER_PATH/Frameworks and dylibs in $CONTENTS_FOLDER_PATH/Libraries.
>
> WDYT?
>
> Regards,
> --
> Adam Strzelecki
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
QLibraryInfo::location / qt.conf and such will need to be looked at as well to properly support an @rpath build of Qt. Thiago knows more about this.
--
Jake Petroules - jake.petroules at petroules.com
Chief Technology Officer - Petroules Corporation
From ono at java.pl Fri Aug 1 22:01:30 2014
From: ono at java.pl (Adam Strzelecki)
Date: Fri, 1 Aug 2014 21:01:30 +0200
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
References:
<65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
Message-ID:
>> All we need to do is build all Qt dylibs with install_name = @rpath/pathrelative_to_lib_folder/some.dylib and make sure qmake adds following linker flags to all apps linking to Qt:
>
> Just @rpath/QtModuleName.framework/Versions/A/QtModuleName and @rpath/qtsomethingorother.dylib
I am sorry, you are right, we don't have umbrella frameworks in Qt so this should be sufficient.
> No - don't include the last one. macdeployqt (nor any other tool) should NOT modify the binaries at all (modifying is bad for codesigning too). This is why we have DYLD_LIBRARY_PATH (see below).
I believe we had this discussion in the bug report thread. The problem with DYLD_LIBRARY_PATH is that you need to inject it somehow to process launching the app:
(1) if we put it into Info.plist it won't work for bundle less apps (i.e. for simple testing)
(2) if we put it into user's .bash_profile then it won't work in apps launched via Finder, as launchd does not run/respect .bash_profile
(3) if we use launched setenv it will work just for single UI session
(4) if we put it /etc/launchd-user.conf then we need admin rights + we may likely break other apps
So altogether this is safest solution. Please note that if we gonna deploy Qt frameworks via macdeployqt we need to resign application anyway because app bundle gonna be changed.
> No, QMAKE_INSTALLNAMEPREFIX, which is set to "@rpath" (as opposed to an absolute path as is done currently).
You're right, this is much simpler. Of course my previous solution was considering umbrella frameworks, or frameworks having plugins inside of them, that's why prefix matching.
>> Once this is done qtbase Qmake project should define QMAKE_RPATHPREFIX to be Qt SDK install_prefix/lib during build process.
>
> No replacement needs to be done. (…)
I meant changes that has to be done in Qt SDK build process itself (which is defined in quake projects in qtbase repo). In this case each Qt module should set QMAKE_INSTALLNAMEPREFIX=@rpath on Mac.
> export QT_INSTALL_LIBS=$(qmake -query QT_INSTALL_LIBS)
> export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$QT_INSTALL_LIBS
> /apps/MyApp.app/Contents/MacOS/MyApp
This solution will work only if you are going to launch the app in terminal or your tool (i.e. Qt Creator) will be able to figure out it needs to set DYLD_LIBRARY_PATH which is far to complicated.
> What might be good, too, is a QMAKE_EMBEDDED_FRAMEWORKS or somesuch which copies the Qt frameworks into the application bundle at build time (though you'd still set DYLD_LIBRARY_PATH because not everyone would necessarily use QMAKE_EMBEDDED_FRAMEWORKS). No reason to postpone that step to macdeployqt; this is how the native Apple tools work anyways. Ossi will disagree with me here and say that anything to do with creating bundle structures is a deployment step only, though. :)
Well, to be frank there is a simple workaround for that :) Why not symlink Qt frameworks at build time, then replace symlinks with real copies on deployment step?
So the easiest solution would be to symlink Qt frameworks when your create app bundle otherwise add /full/path/to/qt when you use bundle-less app. No need to mess with DYLD_LIBRARY_PATH.
> Also, I'd add @executable_path/../Libraries and @loader_path/../Libraries to the search path as well. While less commonly known/used (and found in at least some official Apple documentation), some people do like to put frameworks in $CONTENTS_FOLDER_PATH/Frameworks and dylibs in $CONTENTS_FOLDER_PATH/Libraries.
I don't think you should add these by default since Qt doesn't need them, so unlikely your app need them. If you use some 2rd party library you are free to extend QMAKE_RPATH list yourself.
Cheers,
--
Adam
From ono at java.pl Fri Aug 1 22:01:30 2014
From: ono at java.pl (Adam Strzelecki)
Date: Fri, 1 Aug 2014 21:01:30 +0200
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
References:
<65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
Message-ID:
>> All we need to do is build all Qt dylibs with install_name = @rpath/pathrelative_to_lib_folder/some.dylib and make sure qmake adds following linker flags to all apps linking to Qt:
>
> Just @rpath/QtModuleName.framework/Versions/A/QtModuleName and @rpath/qtsomethingorother.dylib
I am sorry, you are right, we don't have umbrella frameworks in Qt so this should be sufficient.
> No - don't include the last one. macdeployqt (nor any other tool) should NOT modify the binaries at all (modifying is bad for codesigning too). This is why we have DYLD_LIBRARY_PATH (see below).
I believe we had this discussion in the bug report thread. The problem with DYLD_LIBRARY_PATH is that you need to inject it somehow to process launching the app:
(1) if we put it into Info.plist it won't work for bundle less apps (i.e. for simple testing)
(2) if we put it into user's .bash_profile then it won't work in apps launched via Finder, as launchd does not run/respect .bash_profile
(3) if we use launched setenv it will work just for single UI session
(4) if we put it /etc/launchd-user.conf then we need admin rights + we may likely break other apps
So altogether this is safest solution. Please note that if we gonna deploy Qt frameworks via macdeployqt we need to resign application anyway because app bundle gonna be changed.
> No, QMAKE_INSTALLNAMEPREFIX, which is set to "@rpath" (as opposed to an absolute path as is done currently).
You're right, this is much simpler. Of course my previous solution was considering umbrella frameworks, or frameworks having plugins inside of them, that's why prefix matching.
>> Once this is done qtbase Qmake project should define QMAKE_RPATHPREFIX to be Qt SDK install_prefix/lib during build process.
>
> No replacement needs to be done. (…)
I meant changes that has to be done in Qt SDK build process itself (which is defined in quake projects in qtbase repo). In this case each Qt module should set QMAKE_INSTALLNAMEPREFIX=@rpath on Mac.
> export QT_INSTALL_LIBS=$(qmake -query QT_INSTALL_LIBS)
> export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$QT_INSTALL_LIBS
> /apps/MyApp.app/Contents/MacOS/MyApp
This solution will work only if you are going to launch the app in terminal or your tool (i.e. Qt Creator) will be able to figure out it needs to set DYLD_LIBRARY_PATH which is far to complicated.
> What might be good, too, is a QMAKE_EMBEDDED_FRAMEWORKS or somesuch which copies the Qt frameworks into the application bundle at build time (though you'd still set DYLD_LIBRARY_PATH because not everyone would necessarily use QMAKE_EMBEDDED_FRAMEWORKS). No reason to postpone that step to macdeployqt; this is how the native Apple tools work anyways. Ossi will disagree with me here and say that anything to do with creating bundle structures is a deployment step only, though. :)
Well, to be frank there is a simple workaround for that :) Why not symlink Qt frameworks at build time, then replace symlinks with real copies on deployment step?
So the easiest solution would be to symlink Qt frameworks when your create app bundle otherwise add /full/path/to/qt when you use bundle-less app. No need to mess with DYLD_LIBRARY_PATH.
> Also, I'd add @executable_path/../Libraries and @loader_path/../Libraries to the search path as well. While less commonly known/used (and found in at least some official Apple documentation), some people do like to put frameworks in $CONTENTS_FOLDER_PATH/Frameworks and dylibs in $CONTENTS_FOLDER_PATH/Libraries.
I don't think you should add these by default since Qt doesn't need them, so unlikely your app need them. If you use some 2rd party library you are free to extend QMAKE_RPATH list yourself.
Cheers,
--
Adam
From fromqt at tungware.se Fri Aug 1 23:00:53 2014
From: fromqt at tungware.se (Henry Skoglund)
Date: Fri, 01 Aug 2014 22:00:53 +0200
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To:
References: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
Message-ID: <53DBF1F5.7030401@tungware.se>
On 2014-08-01 21:01, Adam Strzelecki wrote:
>...
> Well, to be frank there is a simple workaround for that :) Why not
symlink Qt frameworks at build time, then replace symlinks with real
copies on deployment step?
>
> So the easiest solution would be to symlink Qt frameworks when your
create app bundle otherwise add /full/path/to/qt when you use
bundle-less app. No need to mess with DYLD_LIBRARY_PATH.
>
>...
Please don't add more file I/O to Qt Creator's build effort, at least
not until Apple switches to BTRFS, since HFS+ can be a real dog
sometimes (compared to Ext4 or NTFS).
Also, a bit of topic, but re. how to divide work between macdeployqt and
Qt Creator, and which one should support @rpath; one way to solve this
would be for Qt Creator to usurp macdeployt, i.e. add a Build for
Distribution menu choice in Qt Creator.
Rgrds Henry
From fromqt at tungware.se Fri Aug 1 23:00:53 2014
From: fromqt at tungware.se (Henry Skoglund)
Date: Fri, 01 Aug 2014 22:00:53 +0200
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To:
References: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
Message-ID: <53DBF1F5.7030401@tungware.se>
On 2014-08-01 21:01, Adam Strzelecki wrote:
>...
> Well, to be frank there is a simple workaround for that :) Why not
symlink Qt frameworks at build time, then replace symlinks with real
copies on deployment step?
>
> So the easiest solution would be to symlink Qt frameworks when your
create app bundle otherwise add /full/path/to/qt when you use
bundle-less app. No need to mess with DYLD_LIBRARY_PATH.
>
>...
Please don't add more file I/O to Qt Creator's build effort, at least
not until Apple switches to BTRFS, since HFS+ can be a real dog
sometimes (compared to Ext4 or NTFS).
Also, a bit of topic, but re. how to divide work between macdeployqt and
Qt Creator, and which one should support @rpath; one way to solve this
would be for Qt Creator to usurp macdeployt, i.e. add a Build for
Distribution menu choice in Qt Creator.
Rgrds Henry
From marc.mutz at kdab.com Sat Aug 2 00:16:40 2014
From: marc.mutz at kdab.com (Marc Mutz)
Date: Fri, 1 Aug 2014 23:16:40 +0200
Subject: [Development] [docs/c++] How do we deal with the special member
functions (copy/move ctor/assignment operator, dtor, default ctor)
Message-ID: <201408012316.40275.marc.mutz@kdab.com>
Hi,
As part of the move to C++11, we have dropped some user-defined special member
functions from the API if they weren't doing anything else than the ones the
compiler implicitly creates for us. This has the advantage that a C++11
compiler will create move ctors without the need for #ifdef'ing them It does
that if the class does not have a user-defined copy ctor, among other criteria.
That leaves the question how to deal with the documentation for these implicit
members.
One way would be to add them in an #ifdef Q_QDOC block and document them.
A better way would be to make qdoc generate some abstract docs for them
automatically.
However, unless someone takes it upon himself to implement the C++11 rules
governing the deletedness or existence of these special member functions, a
middle way could be a \deletedcopyctor / \defaultcopyctor in the \class
documentation, maybe?
Thanks,
Marc
--
Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin
Marc Mutz | Senior 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
From marc.mutz at kdab.com Sat Aug 2 00:16:40 2014
From: marc.mutz at kdab.com (Marc Mutz)
Date: Fri, 1 Aug 2014 23:16:40 +0200
Subject: [Development] [docs/c++] How do we deal with the special member
functions (copy/move ctor/assignment operator, dtor, default ctor)
Message-ID: <201408012316.40275.marc.mutz@kdab.com>
Hi,
As part of the move to C++11, we have dropped some user-defined special member
functions from the API if they weren't doing anything else than the ones the
compiler implicitly creates for us. This has the advantage that a C++11
compiler will create move ctors without the need for #ifdef'ing them It does
that if the class does not have a user-defined copy ctor, among other criteria.
That leaves the question how to deal with the documentation for these implicit
members.
One way would be to add them in an #ifdef Q_QDOC block and document them.
A better way would be to make qdoc generate some abstract docs for them
automatically.
However, unless someone takes it upon himself to implement the C++11 rules
governing the deletedness or existence of these special member functions, a
middle way could be a \deletedcopyctor / \defaultcopyctor in the \class
documentation, maybe?
Thanks,
Marc
--
Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin
Marc Mutz | Senior 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
From jake.petroules at petroules.com Sat Aug 2 00:22:29 2014
From: jake.petroules at petroules.com (Jake Petroules)
Date: Fri, 1 Aug 2014 17:22:29 -0400
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To:
References:
<65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
Message-ID: <95C5F7CF-49AD-46B6-A423-988C6E9EF2A2@petroules.com>
On 2014-08-01, at 03:01 PM, Adam Strzelecki wrote:
>>> All we need to do is build all Qt dylibs with install_name = @rpath/pathrelative_to_lib_folder/some.dylib and make sure qmake adds following linker flags to all apps linking to Qt:
>>
>> Just @rpath/QtModuleName.framework/Versions/A/QtModuleName and @rpath/qtsomethingorother.dylib
>
> I am sorry, you are right, we don't have umbrella frameworks in Qt so this should be sufficient.
>
>> No - don't include the last one. macdeployqt (nor any other tool) should NOT modify the binaries at all (modifying is bad for codesigning too). This is why we have DYLD_LIBRARY_PATH (see below).
>
> I believe we had this discussion in the bug report thread. The problem with DYLD_LIBRARY_PATH is that you need to inject it somehow to process launching the app:
>
> (1) if we put it into Info.plist it won't work for bundle less apps (i.e. for simple testing)
Actually you CAN add Info.plist to bundle-less apps using the linker arguments: `-sectcreate __TEXT __info_plist Info.plist` which will embed it in the binary. All OS X APIs handle this transparently. Though, LSEnvironment is not a good solution for the problem we are trying to solve here.
> (2) if we put it into user's .bash_profile then it won't work in apps launched via Finder, as launchd does not run/respect .bash_profile
> (3) if we use launched setenv it will work just for single UI session
> (4) if we put it /etc/launchd-user.conf then we need admin rights + we may likely break other apps
Why would you do any of these things?
> So altogether this is safest solution. Please note that if we gonna deploy Qt frameworks via macdeployqt we need to resign application anyway because app bundle gonna be changed.
"Inject"? DYLD_LIBRARY_PATH is an environment variable. You simply set it in the process's environment before spawning. This is the correct solution and is neither difficult nor error prone. It is something you do only during development time (i.e. in Creator or qbs); once the app is deployed with macdeployqt, the frameworks will be copied into the bundle and setting DYLD_LIBRARY_PATH is no longer necessary.
In a terminal session, simply:
$ export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/path/to/Qt/Frameworks
$ open /apps/MyApp.app
In Creator, just click run and this will be handled automatically. In qbs just type `qbs run -p foo` and this will be handled automatically.
@rpath and DYLD_LIBRARY_PATH exist for good reasons, we must use them properly, not a halfway solution. ANY solution that involves placing absolute paths in ANY file inside the MyApp.app/ directory tree is a wrong solution. Note that Qt Creator already does the logical equivalent of what I described on Windows; the Qt libraries path is added to the PATH when the process is launched. Launching directly in Explorer doesn't work, and launching directly from Finder doesn't need to work either.
However, if we add a QMAKE_EMBEDDED_FRAMEWORKS variable, essentially rolling macdeployqt functionality directly into qmake, then it would work when launched in Finder. This is closer to how the native tools do things anyways, but DYLD_LIBRARY_PATH should still be set by Creator/qbs regardless of whether that is added.
>> No, QMAKE_INSTALLNAMEPREFIX, which is set to "@rpath" (as opposed to an absolute path as is done currently).
>
> You're right, this is much simpler. Of course my previous solution was considering umbrella frameworks, or frameworks having plugins inside of them, that's why prefix matching.
No need for prefix matching even if you do this. Plugins embedded in their respective frameworks would actually make a lot of sense. Just add more rpaths to the Qt plugins, like @loader_path/../../../Frameworks or however many levels it is.
>>> Once this is done qtbase Qmake project should define QMAKE_RPATHPREFIX to be Qt SDK install_prefix/lib during build process.
>>
>> No replacement needs to be done. (…)
>
> I meant changes that has to be done in Qt SDK build process itself (which is defined in quake projects in qtbase repo). In this case each Qt module should set QMAKE_INSTALLNAMEPREFIX=@rpath on Mac.
>
>> export QT_INSTALL_LIBS=$(qmake -query QT_INSTALL_LIBS)
>> export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$QT_INSTALL_LIBS
>> /apps/MyApp.app/Contents/MacOS/MyApp
>
> This solution will work only if you are going to launch the app in terminal or your tool (i.e. Qt Creator) will be able to figure out it needs to set DYLD_LIBRARY_PATH which is far to complicated.
I'm a bit confused by your sentence structure. Are you saying it's complicated for Qt Creator to figure out if it needs to set DYLD_LIBRARY_PATH? It isn't. The value is `qmake -query QT_INSTALL_LIBS`. As I said above, there is no requirement that the application be launchable directly from Finder (doesn't work on Windows from Explorer either) at development time.
>> What might be good, too, is a QMAKE_EMBEDDED_FRAMEWORKS or somesuch which copies the Qt frameworks into the application bundle at build time (though you'd still set DYLD_LIBRARY_PATH because not everyone would necessarily use QMAKE_EMBEDDED_FRAMEWORKS). No reason to postpone that step to macdeployqt; this is how the native Apple tools work anyways. Ossi will disagree with me here and say that anything to do with creating bundle structures is a deployment step only, though. :)
>
> Well, to be frank there is a simple workaround for that :) Why not symlink Qt frameworks at build time, then replace symlinks with real copies on deployment step?
>
> So the easiest solution would be to symlink Qt frameworks when your create app bundle otherwise add /full/path/to/qt when you use bundle-less app. No need to mess with DYLD_LIBRARY_PATH.
Symlinks make no sense. Just copy the full frameworks, there is no disadvantage to this. This is the standard workflow for development on Apple platforms anyways and has been since NeXTSTEP. I'm sure someone will bring up "performance!!1" but that is a poor argument;
(1) It can be optimized; you're not going to copy the entire frameworks every single time you press build.
(2) In the NeXTSTEP days, computers were much slower and no one had SSDs, despite this;
(3) Of all the OS X applications that exist, very few use Qt and I have NEVER seen a single complaint about the supposed performance implications of copying frameworks at build time like is done for the vast majority of OS X applications built with Xcode. Let's focus on REAL bottlenecks that actually cause performance problems, instead of an extremely minor one that actually solves the major problem we are concerned with.
(4) No one's forced - simply copy the frameworks at build time for normal people, and premature optimizing performance pedants can use the DYLD_LIBRARY_PATH based solution. This is why I proposed a QMAKE_EMBEDDED_FRAMEWORKS, pedants need not set it. Everyone's happy.
>> Also, I'd add @executable_path/../Libraries and @loader_path/../Libraries to the search path as well. While less commonly known/used (and found in at least some official Apple documentation), some people do like to put frameworks in $CONTENTS_FOLDER_PATH/Frameworks and dylibs in $CONTENTS_FOLDER_PATH/Libraries.
>
> I don't think you should add these by default since Qt doesn't need them, so unlikely your app need them. If you use some 2rd party library you are free to extend QMAKE_RPATH list yourself.
It might need them. Depends if we change macdeployqt to place a dylibs (non-frameworks) build of Qt libraries inside Libraries instead of Frameworks. Not a major part of the discussion anyways, just an idea.
> Cheers,
> --
> Adam
Finally, I want to stress: OS X and iOS are not like other platforms. They are not Windows, or Android, or Linux, or BlackBerry, or FreeBSD. They have a unique set of standards and workflows that tend to be very different from others and it's futile to attempt to shoehorn ideas from other platforms into how things "should" work. It results in a poor developer (and user) experience and makes Qt unnecessarily difficult to work with on OS X at the present time.
Let's use standard solutions instead of strange contraptions. Standard solutions involve @rpath along with DYLD_LIBRARY_PATH, copying frameworks at build time, or both (preferably both). Not symlinks, not LSEnvironment or other global configurations, not modifying Qt libraries at any point after installation, and not embedding absolute paths in ANY files that are part of the application bundle.
--
Jake Petroules - jake.petroules at petroules.com
Chief Technology Officer - Petroules Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jake.petroules at petroules.com Sat Aug 2 00:22:29 2014
From: jake.petroules at petroules.com (Jake Petroules)
Date: Fri, 1 Aug 2014 17:22:29 -0400
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To:
References:
<65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
Message-ID: <95C5F7CF-49AD-46B6-A423-988C6E9EF2A2@petroules.com>
On 2014-08-01, at 03:01 PM, Adam Strzelecki wrote:
>>> All we need to do is build all Qt dylibs with install_name = @rpath/pathrelative_to_lib_folder/some.dylib and make sure qmake adds following linker flags to all apps linking to Qt:
>>
>> Just @rpath/QtModuleName.framework/Versions/A/QtModuleName and @rpath/qtsomethingorother.dylib
>
> I am sorry, you are right, we don't have umbrella frameworks in Qt so this should be sufficient.
>
>> No - don't include the last one. macdeployqt (nor any other tool) should NOT modify the binaries at all (modifying is bad for codesigning too). This is why we have DYLD_LIBRARY_PATH (see below).
>
> I believe we had this discussion in the bug report thread. The problem with DYLD_LIBRARY_PATH is that you need to inject it somehow to process launching the app:
>
> (1) if we put it into Info.plist it won't work for bundle less apps (i.e. for simple testing)
Actually you CAN add Info.plist to bundle-less apps using the linker arguments: `-sectcreate __TEXT __info_plist Info.plist` which will embed it in the binary. All OS X APIs handle this transparently. Though, LSEnvironment is not a good solution for the problem we are trying to solve here.
> (2) if we put it into user's .bash_profile then it won't work in apps launched via Finder, as launchd does not run/respect .bash_profile
> (3) if we use launched setenv it will work just for single UI session
> (4) if we put it /etc/launchd-user.conf then we need admin rights + we may likely break other apps
Why would you do any of these things?
> So altogether this is safest solution. Please note that if we gonna deploy Qt frameworks via macdeployqt we need to resign application anyway because app bundle gonna be changed.
"Inject"? DYLD_LIBRARY_PATH is an environment variable. You simply set it in the process's environment before spawning. This is the correct solution and is neither difficult nor error prone. It is something you do only during development time (i.e. in Creator or qbs); once the app is deployed with macdeployqt, the frameworks will be copied into the bundle and setting DYLD_LIBRARY_PATH is no longer necessary.
In a terminal session, simply:
$ export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/path/to/Qt/Frameworks
$ open /apps/MyApp.app
In Creator, just click run and this will be handled automatically. In qbs just type `qbs run -p foo` and this will be handled automatically.
@rpath and DYLD_LIBRARY_PATH exist for good reasons, we must use them properly, not a halfway solution. ANY solution that involves placing absolute paths in ANY file inside the MyApp.app/ directory tree is a wrong solution. Note that Qt Creator already does the logical equivalent of what I described on Windows; the Qt libraries path is added to the PATH when the process is launched. Launching directly in Explorer doesn't work, and launching directly from Finder doesn't need to work either.
However, if we add a QMAKE_EMBEDDED_FRAMEWORKS variable, essentially rolling macdeployqt functionality directly into qmake, then it would work when launched in Finder. This is closer to how the native tools do things anyways, but DYLD_LIBRARY_PATH should still be set by Creator/qbs regardless of whether that is added.
>> No, QMAKE_INSTALLNAMEPREFIX, which is set to "@rpath" (as opposed to an absolute path as is done currently).
>
> You're right, this is much simpler. Of course my previous solution was considering umbrella frameworks, or frameworks having plugins inside of them, that's why prefix matching.
No need for prefix matching even if you do this. Plugins embedded in their respective frameworks would actually make a lot of sense. Just add more rpaths to the Qt plugins, like @loader_path/../../../Frameworks or however many levels it is.
>>> Once this is done qtbase Qmake project should define QMAKE_RPATHPREFIX to be Qt SDK install_prefix/lib during build process.
>>
>> No replacement needs to be done. (…)
>
> I meant changes that has to be done in Qt SDK build process itself (which is defined in quake projects in qtbase repo). In this case each Qt module should set QMAKE_INSTALLNAMEPREFIX=@rpath on Mac.
>
>> export QT_INSTALL_LIBS=$(qmake -query QT_INSTALL_LIBS)
>> export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$QT_INSTALL_LIBS
>> /apps/MyApp.app/Contents/MacOS/MyApp
>
> This solution will work only if you are going to launch the app in terminal or your tool (i.e. Qt Creator) will be able to figure out it needs to set DYLD_LIBRARY_PATH which is far to complicated.
I'm a bit confused by your sentence structure. Are you saying it's complicated for Qt Creator to figure out if it needs to set DYLD_LIBRARY_PATH? It isn't. The value is `qmake -query QT_INSTALL_LIBS`. As I said above, there is no requirement that the application be launchable directly from Finder (doesn't work on Windows from Explorer either) at development time.
>> What might be good, too, is a QMAKE_EMBEDDED_FRAMEWORKS or somesuch which copies the Qt frameworks into the application bundle at build time (though you'd still set DYLD_LIBRARY_PATH because not everyone would necessarily use QMAKE_EMBEDDED_FRAMEWORKS). No reason to postpone that step to macdeployqt; this is how the native Apple tools work anyways. Ossi will disagree with me here and say that anything to do with creating bundle structures is a deployment step only, though. :)
>
> Well, to be frank there is a simple workaround for that :) Why not symlink Qt frameworks at build time, then replace symlinks with real copies on deployment step?
>
> So the easiest solution would be to symlink Qt frameworks when your create app bundle otherwise add /full/path/to/qt when you use bundle-less app. No need to mess with DYLD_LIBRARY_PATH.
Symlinks make no sense. Just copy the full frameworks, there is no disadvantage to this. This is the standard workflow for development on Apple platforms anyways and has been since NeXTSTEP. I'm sure someone will bring up "performance!!1" but that is a poor argument;
(1) It can be optimized; you're not going to copy the entire frameworks every single time you press build.
(2) In the NeXTSTEP days, computers were much slower and no one had SSDs, despite this;
(3) Of all the OS X applications that exist, very few use Qt and I have NEVER seen a single complaint about the supposed performance implications of copying frameworks at build time like is done for the vast majority of OS X applications built with Xcode. Let's focus on REAL bottlenecks that actually cause performance problems, instead of an extremely minor one that actually solves the major problem we are concerned with.
(4) No one's forced - simply copy the frameworks at build time for normal people, and premature optimizing performance pedants can use the DYLD_LIBRARY_PATH based solution. This is why I proposed a QMAKE_EMBEDDED_FRAMEWORKS, pedants need not set it. Everyone's happy.
>> Also, I'd add @executable_path/../Libraries and @loader_path/../Libraries to the search path as well. While less commonly known/used (and found in at least some official Apple documentation), some people do like to put frameworks in $CONTENTS_FOLDER_PATH/Frameworks and dylibs in $CONTENTS_FOLDER_PATH/Libraries.
>
> I don't think you should add these by default since Qt doesn't need them, so unlikely your app need them. If you use some 2rd party library you are free to extend QMAKE_RPATH list yourself.
It might need them. Depends if we change macdeployqt to place a dylibs (non-frameworks) build of Qt libraries inside Libraries instead of Frameworks. Not a major part of the discussion anyways, just an idea.
> Cheers,
> --
> Adam
Finally, I want to stress: OS X and iOS are not like other platforms. They are not Windows, or Android, or Linux, or BlackBerry, or FreeBSD. They have a unique set of standards and workflows that tend to be very different from others and it's futile to attempt to shoehorn ideas from other platforms into how things "should" work. It results in a poor developer (and user) experience and makes Qt unnecessarily difficult to work with on OS X at the present time.
Let's use standard solutions instead of strange contraptions. Standard solutions involve @rpath along with DYLD_LIBRARY_PATH, copying frameworks at build time, or both (preferably both). Not symlinks, not LSEnvironment or other global configurations, not modifying Qt libraries at any point after installation, and not embedding absolute paths in ANY files that are part of the application bundle.
--
Jake Petroules - jake.petroules at petroules.com
Chief Technology Officer - Petroules Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jake.petroules at petroules.com Sat Aug 2 00:34:46 2014
From: jake.petroules at petroules.com (Jake Petroules)
Date: Fri, 1 Aug 2014 17:34:46 -0400
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To: <53DBF1F5.7030401@tungware.se>
References: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
<53DBF1F5.7030401@tungware.se>
Message-ID: <4BF629EA-C68A-434B-A042-27EA671D92FF@petroules.com>
On 2014-08-01, at 04:00 PM, Henry Skoglund wrote:
> On 2014-08-01 21:01, Adam Strzelecki wrote:
>> ...
>> Well, to be frank there is a simple workaround for that :) Why not
> symlink Qt frameworks at build time, then replace symlinks with real
> copies on deployment step?
>>
>> So the easiest solution would be to symlink Qt frameworks when your
> create app bundle otherwise add /full/path/to/qt when you use
> bundle-less app. No need to mess with DYLD_LIBRARY_PATH.
>>
>> ...
>
> Please don't add more file I/O to Qt Creator's build effort, at least
> not until Apple switches to BTRFS, since HFS+ can be a real dog
> sometimes (compared to Ext4 or NTFS).
Please don't exaggerate the performance implications of copying a few frameworks on the first build, and checking a few timestamps on each subsequent build. You'll be waiting quite literally 1000 times longer for make to finish executing. Also, all new Macs have SSDs which greatly accelerates filesystem I/O (even if it were enough to be a concern, which it isn't).
Unless you can benchmark it and prove the average build time increases by more than 400ms by using a copy-frameworks-to-bundle strategy, it's a non issue.
> Also, a bit of topic, but re. how to divide work between macdeployqt and
> Qt Creator, and which one should support @rpath; one way to solve this
> would be for Qt Creator to usurp macdeployt, i.e. add a Build for
> Distribution menu choice in Qt Creator.
>
> Rgrds Henry
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
--
Jake Petroules - jake.petroules at petroules.com
Chief Technology Officer - Petroules Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jake.petroules at petroules.com Sat Aug 2 00:34:46 2014
From: jake.petroules at petroules.com (Jake Petroules)
Date: Fri, 1 Aug 2014 17:34:46 -0400
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To: <53DBF1F5.7030401@tungware.se>
References: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
<53DBF1F5.7030401@tungware.se>
Message-ID: <4BF629EA-C68A-434B-A042-27EA671D92FF@petroules.com>
On 2014-08-01, at 04:00 PM, Henry Skoglund wrote:
> On 2014-08-01 21:01, Adam Strzelecki wrote:
>> ...
>> Well, to be frank there is a simple workaround for that :) Why not
> symlink Qt frameworks at build time, then replace symlinks with real
> copies on deployment step?
>>
>> So the easiest solution would be to symlink Qt frameworks when your
> create app bundle otherwise add /full/path/to/qt when you use
> bundle-less app. No need to mess with DYLD_LIBRARY_PATH.
>>
>> ...
>
> Please don't add more file I/O to Qt Creator's build effort, at least
> not until Apple switches to BTRFS, since HFS+ can be a real dog
> sometimes (compared to Ext4 or NTFS).
Please don't exaggerate the performance implications of copying a few frameworks on the first build, and checking a few timestamps on each subsequent build. You'll be waiting quite literally 1000 times longer for make to finish executing. Also, all new Macs have SSDs which greatly accelerates filesystem I/O (even if it were enough to be a concern, which it isn't).
Unless you can benchmark it and prove the average build time increases by more than 400ms by using a copy-frameworks-to-bundle strategy, it's a non issue.
> Also, a bit of topic, but re. how to divide work between macdeployqt and
> Qt Creator, and which one should support @rpath; one way to solve this
> would be for Qt Creator to usurp macdeployt, i.e. add a Build for
> Distribution menu choice in Qt Creator.
>
> Rgrds Henry
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
--
Jake Petroules - jake.petroules at petroules.com
Chief Technology Officer - Petroules Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From thomas.senyk at pelagicore.com Sat Aug 2 09:35:50 2014
From: thomas.senyk at pelagicore.com (thomas.senyk at pelagicore.com)
Date: Sat, 02 Aug 2014 08:35:50 +0200
Subject: [Development] bitbake meta-toolchain error
In-Reply-To:
References:
Message-ID: <45389886.XWi926jlrp@comet>
EGL "thinks" (as in defines) it's a framebuffer build, Qt tries to build the
XCB plugin .. shouldn't happen when removing x11 from distro_features.
Have you 'bitbake'ed before adding DISTRO_FREATURES_remove ... ?
If so consider to start over with a fresh build because it might be a bit
hard to get rid of all X11 traces.
You should go into meta-qt5, remove all "-silent" ... no clue why a managed
build system would want to have "-silent" ..
If the errors persists also add the log for configure.
On Friday, August 01, 2014 02:49:55 PM Nilesh Kokane wrote:
> Hello,
>
>
>
> I followed
> http://wiki.wandboard.org/index.php/Building_Qt5_using_yocto_on_Wandboard
> (newly added)
>
>
> The DISTRO_FEATURES_remove = "x11 wayland" is removed from the local.conf
>
>
> And after giving the bitbake core-image-minimal I'm logged with the errors
> as posted on pastebin http://pastebin.com/hsMhT9f8
>
>
>
>
> ERROR: Function failed: do_compile (log file is located at
> /home/minda/bin/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-mx6-pok
> y-linux-gnueabi/qtbase/5.2.1-r0/temp/log.do_compile.28369) ERROR: Logfile of
> failure stored in:
> /home/minda/bin/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-mx6-pok
> y-linux-gnueabi/qtbase/5.2.1-r0/temp/log.do_compile.28369
>
>
>
> ERROR: Task 655
> (/home/minda/bin/fsl-community-bsp/sources/meta-qt5/recipes-qt/qt5/
> qtbase_5.2.1.bb, do_compile) failed with exit code '1'
>
>
>
>
>
> can anyone suggest.
From ono at java.pl Fri Aug 1 22:01:30 2014
From: ono at java.pl (Adam Strzelecki)
Date: Fri, 1 Aug 2014 21:01:30 +0200
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
References:
<65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
Message-ID:
>> All we need to do is build all Qt dylibs with install_name = @rpath/pathrelative_to_lib_folder/some.dylib and make sure qmake adds following linker flags to all apps linking to Qt:
>
> Just @rpath/QtModuleName.framework/Versions/A/QtModuleName and @rpath/qtsomethingorother.dylib
I am sorry, you are right, we don't have umbrella frameworks in Qt so this should be sufficient.
> No - don't include the last one. macdeployqt (nor any other tool) should NOT modify the binaries at all (modifying is bad for codesigning too). This is why we have DYLD_LIBRARY_PATH (see below).
I believe we had this discussion in the bug report thread. The problem with DYLD_LIBRARY_PATH is that you need to inject it somehow to process launching the app:
(1) if we put it into Info.plist it won't work for bundle less apps (i.e. for simple testing)
(2) if we put it into user's .bash_profile then it won't work in apps launched via Finder, as launchd does not run/respect .bash_profile
(3) if we use launched setenv it will work just for single UI session
(4) if we put it /etc/launchd-user.conf then we need admin rights + we may likely break other apps
So altogether this is safest solution. Please note that if we gonna deploy Qt frameworks via macdeployqt we need to resign application anyway because app bundle gonna be changed.
> No, QMAKE_INSTALLNAMEPREFIX, which is set to "@rpath" (as opposed to an absolute path as is done currently).
You're right, this is much simpler. Of course my previous solution was considering umbrella frameworks, or frameworks having plugins inside of them, that's why prefix matching.
>> Once this is done qtbase Qmake project should define QMAKE_RPATHPREFIX to be Qt SDK install_prefix/lib during build process.
>
> No replacement needs to be done. (…)
I meant changes that has to be done in Qt SDK build process itself (which is defined in quake projects in qtbase repo). In this case each Qt module should set QMAKE_INSTALLNAMEPREFIX=@rpath on Mac.
> export QT_INSTALL_LIBS=$(qmake -query QT_INSTALL_LIBS)
> export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$QT_INSTALL_LIBS
> /apps/MyApp.app/Contents/MacOS/MyApp
This solution will work only if you are going to launch the app in terminal or your tool (i.e. Qt Creator) will be able to figure out it needs to set DYLD_LIBRARY_PATH which is far to complicated.
> What might be good, too, is a QMAKE_EMBEDDED_FRAMEWORKS or somesuch which copies the Qt frameworks into the application bundle at build time (though you'd still set DYLD_LIBRARY_PATH because not everyone would necessarily use QMAKE_EMBEDDED_FRAMEWORKS). No reason to postpone that step to macdeployqt; this is how the native Apple tools work anyways. Ossi will disagree with me here and say that anything to do with creating bundle structures is a deployment step only, though. :)
Well, to be frank there is a simple workaround for that :) Why not symlink Qt frameworks at build time, then replace symlinks with real copies on deployment step?
So the easiest solution would be to symlink Qt frameworks when your create app bundle otherwise add /full/path/to/qt when you use bundle-less app. No need to mess with DYLD_LIBRARY_PATH.
> Also, I'd add @executable_path/../Libraries and @loader_path/../Libraries to the search path as well. While less commonly known/used (and found in at least some official Apple documentation), some people do like to put frameworks in $CONTENTS_FOLDER_PATH/Frameworks and dylibs in $CONTENTS_FOLDER_PATH/Libraries.
I don't think you should add these by default since Qt doesn't need them, so unlikely your app need them. If you use some 2rd party library you are free to extend QMAKE_RPATH list yourself.
Cheers,
--
Adam
From thomas.senyk at pelagicore.com Sat Aug 2 09:35:50 2014
From: thomas.senyk at pelagicore.com (thomas.senyk at pelagicore.com)
Date: Sat, 02 Aug 2014 08:35:50 +0200
Subject: [Development] bitbake meta-toolchain error
In-Reply-To:
References:
Message-ID: <45389886.XWi926jlrp@comet>
EGL "thinks" (as in defines) it's a framebuffer build, Qt tries to build the
XCB plugin .. shouldn't happen when removing x11 from distro_features.
Have you 'bitbake'ed before adding DISTRO_FREATURES_remove ... ?
If so consider to start over with a fresh build because it might be a bit
hard to get rid of all X11 traces.
You should go into meta-qt5, remove all "-silent" ... no clue why a managed
build system would want to have "-silent" ..
If the errors persists also add the log for configure.
On Friday, August 01, 2014 02:49:55 PM Nilesh Kokane wrote:
> Hello,
>
>
>
> I followed
> http://wiki.wandboard.org/index.php/Building_Qt5_using_yocto_on_Wandboard
> (newly added)
>
>
> The DISTRO_FEATURES_remove = "x11 wayland" is removed from the local.conf
>
>
> And after giving the bitbake core-image-minimal I'm logged with the errors
> as posted on pastebin http://pastebin.com/hsMhT9f8
>
>
>
>
> ERROR: Function failed: do_compile (log file is located at
> /home/minda/bin/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-mx6-pok
> y-linux-gnueabi/qtbase/5.2.1-r0/temp/log.do_compile.28369) ERROR: Logfile of
> failure stored in:
> /home/minda/bin/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-mx6-pok
> y-linux-gnueabi/qtbase/5.2.1-r0/temp/log.do_compile.28369
>
>
>
> ERROR: Task 655
> (/home/minda/bin/fsl-community-bsp/sources/meta-qt5/recipes-qt/qt5/
> qtbase_5.2.1.bb, do_compile) failed with exit code '1'
>
>
>
>
>
> can anyone suggest.
From ono at java.pl Fri Aug 1 22:01:30 2014
From: ono at java.pl (Adam Strzelecki)
Date: Fri, 1 Aug 2014 21:01:30 +0200
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
References:
<65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
Message-ID:
>> All we need to do is build all Qt dylibs with install_name = @rpath/pathrelative_to_lib_folder/some.dylib and make sure qmake adds following linker flags to all apps linking to Qt:
>
> Just @rpath/QtModuleName.framework/Versions/A/QtModuleName and @rpath/qtsomethingorother.dylib
I am sorry, you are right, we don't have umbrella frameworks in Qt so this should be sufficient.
> No - don't include the last one. macdeployqt (nor any other tool) should NOT modify the binaries at all (modifying is bad for codesigning too). This is why we have DYLD_LIBRARY_PATH (see below).
I believe we had this discussion in the bug report thread. The problem with DYLD_LIBRARY_PATH is that you need to inject it somehow to process launching the app:
(1) if we put it into Info.plist it won't work for bundle less apps (i.e. for simple testing)
(2) if we put it into user's .bash_profile then it won't work in apps launched via Finder, as launchd does not run/respect .bash_profile
(3) if we use launched setenv it will work just for single UI session
(4) if we put it /etc/launchd-user.conf then we need admin rights + we may likely break other apps
So altogether this is safest solution. Please note that if we gonna deploy Qt frameworks via macdeployqt we need to resign application anyway because app bundle gonna be changed.
> No, QMAKE_INSTALLNAMEPREFIX, which is set to "@rpath" (as opposed to an absolute path as is done currently).
You're right, this is much simpler. Of course my previous solution was considering umbrella frameworks, or frameworks having plugins inside of them, that's why prefix matching.
>> Once this is done qtbase Qmake project should define QMAKE_RPATHPREFIX to be Qt SDK install_prefix/lib during build process.
>
> No replacement needs to be done. (…)
I meant changes that has to be done in Qt SDK build process itself (which is defined in quake projects in qtbase repo). In this case each Qt module should set QMAKE_INSTALLNAMEPREFIX=@rpath on Mac.
> export QT_INSTALL_LIBS=$(qmake -query QT_INSTALL_LIBS)
> export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$QT_INSTALL_LIBS
> /apps/MyApp.app/Contents/MacOS/MyApp
This solution will work only if you are going to launch the app in terminal or your tool (i.e. Qt Creator) will be able to figure out it needs to set DYLD_LIBRARY_PATH which is far to complicated.
> What might be good, too, is a QMAKE_EMBEDDED_FRAMEWORKS or somesuch which copies the Qt frameworks into the application bundle at build time (though you'd still set DYLD_LIBRARY_PATH because not everyone would necessarily use QMAKE_EMBEDDED_FRAMEWORKS). No reason to postpone that step to macdeployqt; this is how the native Apple tools work anyways. Ossi will disagree with me here and say that anything to do with creating bundle structures is a deployment step only, though. :)
Well, to be frank there is a simple workaround for that :) Why not symlink Qt frameworks at build time, then replace symlinks with real copies on deployment step?
So the easiest solution would be to symlink Qt frameworks when your create app bundle otherwise add /full/path/to/qt when you use bundle-less app. No need to mess with DYLD_LIBRARY_PATH.
> Also, I'd add @executable_path/../Libraries and @loader_path/../Libraries to the search path as well. While less commonly known/used (and found in at least some official Apple documentation), some people do like to put frameworks in $CONTENTS_FOLDER_PATH/Frameworks and dylibs in $CONTENTS_FOLDER_PATH/Libraries.
I don't think you should add these by default since Qt doesn't need them, so unlikely your app need them. If you use some 2rd party library you are free to extend QMAKE_RPATH list yourself.
Cheers,
--
Adam
From ono at java.pl Sat Aug 2 12:04:07 2014
From: ono at java.pl (Adam Strzelecki)
Date: Sat, 2 Aug 2014 11:04:07 +0200
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To: <4BF629EA-C68A-434B-A042-27EA671D92FF@petroules.com>
References: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
<53DBF1F5.7030401@tungware.se>
<4BF629EA-C68A-434B-A042-27EA671D92FF@petroules.com>
Message-ID:
> Please don't exaggerate the performance implications of copying a few frameworks on the first build (…)
This can be done, but discussion is going off-topic.
Let us try first to move Qt frameworks to use @rpath & remove some unnecessary operations while keeping current workflow with minimal changes to the code. Therefore I hereby propose to (1) keep rpath to Qt SDK in built app executable, (2) not copy anything on build, (3) make macdeploy modify ONLY executable removing absolute rpath (instead fixing frameworks), and (4) just copy needed frameworks and (5) optionally sign whole bundle.
This will not require any wrappers, environment variables or changes in Qt Creator to run your app. Only Qmake and macdeploy need to be changed.
Frankly I don't see anything wrong with keeping full path to SDK in executable when it isn't yet completely bundled. And the initial intention was to NOT touch Qt SDK modules once they are built.
Once this is done & working we can follow this discussion and think what can be done next.
--
Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ono at java.pl Sat Aug 2 12:04:07 2014
From: ono at java.pl (Adam Strzelecki)
Date: Sat, 2 Aug 2014 11:04:07 +0200
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To: <4BF629EA-C68A-434B-A042-27EA671D92FF@petroules.com>
References: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
<53DBF1F5.7030401@tungware.se>
<4BF629EA-C68A-434B-A042-27EA671D92FF@petroules.com>
Message-ID:
> Please don't exaggerate the performance implications of copying a few frameworks on the first build (…)
This can be done, but discussion is going off-topic.
Let us try first to move Qt frameworks to use @rpath & remove some unnecessary operations while keeping current workflow with minimal changes to the code. Therefore I hereby propose to (1) keep rpath to Qt SDK in built app executable, (2) not copy anything on build, (3) make macdeploy modify ONLY executable removing absolute rpath (instead fixing frameworks), and (4) just copy needed frameworks and (5) optionally sign whole bundle.
This will not require any wrappers, environment variables or changes in Qt Creator to run your app. Only Qmake and macdeploy need to be changed.
Frankly I don't see anything wrong with keeping full path to SDK in executable when it isn't yet completely bundled. And the initial intention was to NOT touch Qt SDK modules once they are built.
Once this is done & working we can follow this discussion and think what can be done next.
--
Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ono at java.pl Sat Aug 2 12:48:14 2014
From: ono at java.pl (Adam Strzelecki)
Date: Sat, 2 Aug 2014 11:48:14 +0200
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To: <95C5F7CF-49AD-46B6-A423-988C6E9EF2A2@petroules.com>
References:
<65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
<95C5F7CF-49AD-46B6-A423-988C6E9EF2A2@petroules.com>
Message-ID:
> Actually you CAN add Info.plist to bundle-less apps using the linker arguments: `-sectcreate __TEXT __info_plist Info.plist` which will embed it in the binary. All OS X APIs handle this transparently. Though, LSEnvironment is not a good solution for the problem we are trying to solve here.
I was expecting that ;) But wasn't your intention to not modify binary once it has been built and not hardcode any paths into it?
> Why would you do any of these things?
Because you dislike adding absolute rpath to Qt SDK in built binary during dev process.
> "Inject"? DYLD_LIBRARY_PATH is an environment variable. You simply set it in the process's environment before spawning.
It is not so simple, first of all as you shown it works only from console, but if you launch it via GUI you need this variable to be set in launchd. As ~/.launchd.conf doesn't work anymore since Lion only permanent solution is to use /etc/launchd-user.conf which require admin to create/modify.
Secondly DYLD_LIBRARY_PATH has strong security implications as the path is searched BEFORE default locations. So it does in fact let you inject/replace libraries. This is the reason dyld disables that for any process running under root account.
man dyld
DYLD_LIBRARY_PATH
The dynamic linker searches these directories BEFORE it searches the default locations for libraries.
What might be considered there is DYLD_FALLBACK_FRAMEWORK_PATH.
> In a terminal session, simply:
>
> $ export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/path/to/Qt/Frameworks
> $ open /apps/MyApp.app
>
> In Creator, just click run and this will be handled automatically. In qbs just type `qbs run -p foo` and this will be handled automatically.
This won't work for apps launched directly via Finder/Dock.
> ANY solution that involves placing absolute paths in ANY file inside the MyApp.app/ directory tree is a wrong solution.
You are wrong there. All system libs are referenced with their absolute paths.
Moreover the Qt's lib/ absolute path will be there only during development, in deployed binary absolute path will be removed via install_name_tool -delete_rpath.
> Note that Qt Creator already does the logical equivalent of what I described on Windows; the Qt libraries path is added to the PATH when the process is launched. Launching directly in Explorer doesn't work, and launching directly from Finder doesn't need to work either.
Currently it DOES WORK when launching via Finder, because it does hardcode absolute path, so I don't see any reason it should stop working. Also it does work like that on Linux too.
> This is closer to how the native tools do things anyways.
Which tools? AFAIK Xcode doesn't copy external frameworks into app bundle by default.
> Symlinks make no sense. Just copy the full frameworks, there is no disadvantage to this. This is the standard workflow for development on Apple platforms anyways and has been since NeXTSTEP.
See above.
> I'm sure someone will bring up "performance!!1" but that is a poor argument;
This is going off-topic. It was about to bring @rpath to Qt frameworks not rework entire workflow.
>> I don't think you should add these by default since Qt doesn't need them, so unlikely your app need them. If you use some 2rd party library you are free to extend QMAKE_RPATH list yourself.
>
> It might need them. Depends if we change macdeployqt to place a dylibs (non-frameworks) build of Qt libraries inside Libraries instead of Frameworks. Not a major part of the discussion anyways, just an idea.
I don't see point of handling some custom scenarios that anyway are not what is expected (standard) app bundle.
> Let's use standard solutions instead of strange contraptions. Standard solutions involve @rpath along with DYLD_LIBRARY_PATH, copying frameworks at build time, or both (preferably both).
I am sorry, but you are wrong. DYLD_LIBRARY_PATH is nowhere used in Xcode and DYLD_ variables exist for dyld debug purposes.
Try to create simple framework and see what happens, checkout install name of built framework.
$ otool -L /Users/ono/Library/Developer/Xcode/DerivedData/TestFramework-aduwyulqilsereeqgoizoxubgbdy/Build/Products/Debug/TestFramework.framework/TestFramework
/Users/ono/Library/Developer/Xcode/DerivedData/TestFramework-aduwyulqilsereeqgoizoxubgbdy/Build/Products/Debug/TestFramework.framework/TestFramework:
/Library/Frameworks/TestFramework.framework/Versions/A/TestFramework (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 20.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1056.13.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
Now create a Cocoa app and framework from the framework project as see how the framework is referred and check if you can find the framework inside bundle.
$ otool -L /Users/ono/Library/Developer/Xcode/DerivedData/SampleApp-fwmalbohyjlyqgdhjvnicwjqqmfr/Build/Products/Debug/SampleApp.app/Contents/MacOS/SampleApp
/Users/ono/Library/Developer/Xcode/DerivedData/SampleApp-fwmalbohyjlyqgdhjvnicwjqqmfr/Build/Products/Debug/SampleApp.app/Contents/MacOS/SampleApp:
/Library/Frameworks/TestFramework.framework/Versions/A/TestFramework (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 20.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1056.13.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1265.19.0)
--
Adam
From ono at java.pl Sat Aug 2 12:48:14 2014
From: ono at java.pl (Adam Strzelecki)
Date: Sat, 2 Aug 2014 11:48:14 +0200
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To: <95C5F7CF-49AD-46B6-A423-988C6E9EF2A2@petroules.com>
References:
<65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
<95C5F7CF-49AD-46B6-A423-988C6E9EF2A2@petroules.com>
Message-ID:
> Actually you CAN add Info.plist to bundle-less apps using the linker arguments: `-sectcreate __TEXT __info_plist Info.plist` which will embed it in the binary. All OS X APIs handle this transparently. Though, LSEnvironment is not a good solution for the problem we are trying to solve here.
I was expecting that ;) But wasn't your intention to not modify binary once it has been built and not hardcode any paths into it?
> Why would you do any of these things?
Because you dislike adding absolute rpath to Qt SDK in built binary during dev process.
> "Inject"? DYLD_LIBRARY_PATH is an environment variable. You simply set it in the process's environment before spawning.
It is not so simple, first of all as you shown it works only from console, but if you launch it via GUI you need this variable to be set in launchd. As ~/.launchd.conf doesn't work anymore since Lion only permanent solution is to use /etc/launchd-user.conf which require admin to create/modify.
Secondly DYLD_LIBRARY_PATH has strong security implications as the path is searched BEFORE default locations. So it does in fact let you inject/replace libraries. This is the reason dyld disables that for any process running under root account.
man dyld
DYLD_LIBRARY_PATH
The dynamic linker searches these directories BEFORE it searches the default locations for libraries.
What might be considered there is DYLD_FALLBACK_FRAMEWORK_PATH.
> In a terminal session, simply:
>
> $ export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/path/to/Qt/Frameworks
> $ open /apps/MyApp.app
>
> In Creator, just click run and this will be handled automatically. In qbs just type `qbs run -p foo` and this will be handled automatically.
This won't work for apps launched directly via Finder/Dock.
> ANY solution that involves placing absolute paths in ANY file inside the MyApp.app/ directory tree is a wrong solution.
You are wrong there. All system libs are referenced with their absolute paths.
Moreover the Qt's lib/ absolute path will be there only during development, in deployed binary absolute path will be removed via install_name_tool -delete_rpath.
> Note that Qt Creator already does the logical equivalent of what I described on Windows; the Qt libraries path is added to the PATH when the process is launched. Launching directly in Explorer doesn't work, and launching directly from Finder doesn't need to work either.
Currently it DOES WORK when launching via Finder, because it does hardcode absolute path, so I don't see any reason it should stop working. Also it does work like that on Linux too.
> This is closer to how the native tools do things anyways.
Which tools? AFAIK Xcode doesn't copy external frameworks into app bundle by default.
> Symlinks make no sense. Just copy the full frameworks, there is no disadvantage to this. This is the standard workflow for development on Apple platforms anyways and has been since NeXTSTEP.
See above.
> I'm sure someone will bring up "performance!!1" but that is a poor argument;
This is going off-topic. It was about to bring @rpath to Qt frameworks not rework entire workflow.
>> I don't think you should add these by default since Qt doesn't need them, so unlikely your app need them. If you use some 2rd party library you are free to extend QMAKE_RPATH list yourself.
>
> It might need them. Depends if we change macdeployqt to place a dylibs (non-frameworks) build of Qt libraries inside Libraries instead of Frameworks. Not a major part of the discussion anyways, just an idea.
I don't see point of handling some custom scenarios that anyway are not what is expected (standard) app bundle.
> Let's use standard solutions instead of strange contraptions. Standard solutions involve @rpath along with DYLD_LIBRARY_PATH, copying frameworks at build time, or both (preferably both).
I am sorry, but you are wrong. DYLD_LIBRARY_PATH is nowhere used in Xcode and DYLD_ variables exist for dyld debug purposes.
Try to create simple framework and see what happens, checkout install name of built framework.
$ otool -L /Users/ono/Library/Developer/Xcode/DerivedData/TestFramework-aduwyulqilsereeqgoizoxubgbdy/Build/Products/Debug/TestFramework.framework/TestFramework
/Users/ono/Library/Developer/Xcode/DerivedData/TestFramework-aduwyulqilsereeqgoizoxubgbdy/Build/Products/Debug/TestFramework.framework/TestFramework:
/Library/Frameworks/TestFramework.framework/Versions/A/TestFramework (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 20.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1056.13.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
Now create a Cocoa app and framework from the framework project as see how the framework is referred and check if you can find the framework inside bundle.
$ otool -L /Users/ono/Library/Developer/Xcode/DerivedData/SampleApp-fwmalbohyjlyqgdhjvnicwjqqmfr/Build/Products/Debug/SampleApp.app/Contents/MacOS/SampleApp
/Users/ono/Library/Developer/Xcode/DerivedData/SampleApp-fwmalbohyjlyqgdhjvnicwjqqmfr/Build/Products/Debug/SampleApp.app/Contents/MacOS/SampleApp:
/Library/Frameworks/TestFramework.framework/Versions/A/TestFramework (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 20.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1056.13.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1265.19.0)
--
Adam
From nilesh.kokane at mindastoneridge.com Sat Aug 2 15:10:59 2014
From: nilesh.kokane at mindastoneridge.com (Nilesh Kokane)
Date: Sat, 2 Aug 2014 17:40:59 +0530
Subject: [Development] bitbake meta-toolchain error
In-Reply-To: <45389886.XWi926jlrp@comet>
References:
<45389886.XWi926jlrp@comet>
Message-ID:
Hi Thomas,
Thanks for your valuable reply
EGL "thinks" (as in defines) it's a framebuffer build, Qt tries to build the
XCB plugin .. shouldn't happen when removing x11 from distro_features.
I see, but i read that i need to modify the “eglvivante.h” as header files
are not set appropriately when you compile Qt with XCB support.Can you
specify what exactly to alter to counteract on the issue
Have you 'bitbake'ed before adding DISTRO_FREATURES_remove ... ?
If so consider to start over with a fresh build because it might be a bit
hard to get rid of all X11 traces.
Yes I tried both the ways of bitbake , adding DISTRO_FREATURES_remove
DISTRO_FREATURES_remove while present in the local.conf it fails at the
last stage of do_rootfs.The logs are posted here
http://pastebin.com/QFu2Rw6G
You should go into meta-qt5, remove all "-silent" ... no clue why a managed
build system would want to have "-silent" ..
Can you specify which file in the meta-qt5 should be altered to remove
-silent
Please if you can have a look on logs and suggest me.
Thanks
Nilesh Kokane
On Sat, Aug 2, 2014 at 12:05 PM, wrote:
> EGL "thinks" (as in defines) it's a framebuffer build, Qt tries to build
> the
> XCB plugin .. shouldn't happen when removing x11 from distro_features.
>
> Have you 'bitbake'ed before adding DISTRO_FREATURES_remove ... ?
> If so consider to start over with a fresh build because it might be a bit
> hard to get rid of all X11 traces.
>
> You should go into meta-qt5, remove all "-silent" ... no clue why a managed
> build system would want to have "-silent" ..
>
> If the errors persists also add the log for configure.
>
>
> On Friday, August 01, 2014 02:49:55 PM Nilesh Kokane wrote:
> > Hello,
> >
> >
> >
> > I followed
> >
> http://wiki.wandboard.org/index.php/Building_Qt5_using_yocto_on_Wandboard
> > (newly added)
> >
> >
> > The DISTRO_FEATURES_remove = "x11 wayland" is removed from the local.conf
> >
> >
> > And after giving the bitbake core-image-minimal I'm logged with the
> errors
> > as posted on pastebin http://pastebin.com/hsMhT9f8
> >
> >
> >
> >
> > ERROR: Function failed: do_compile (log file is located at
> >
> /home/minda/bin/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-mx6-pok
> > y-linux-gnueabi/qtbase/5.2.1-r0/temp/log.do_compile.28369) ERROR:
> Logfile of
> > failure stored in:
> >
> /home/minda/bin/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-mx6-pok
> > y-linux-gnueabi/qtbase/5.2.1-r0/temp/log.do_compile.28369
> >
> >
> >
> > ERROR: Task 655
> > (/home/minda/bin/fsl-community-bsp/sources/meta-qt5/recipes-qt/qt5/
> > qtbase_5.2.1.bb, do_compile) failed with exit code '1'
> >
> >
> >
> >
> >
> > can anyone suggest.
>
>
--
Thanks
--
“The contents of this e-mail message and any attachments are confidential
and are intended solely for addressee. The information may also be legally
privileged. This transmission is sent in trust, for the sole purpose of
delivery to the intended recipient. If you have received this transmission
in error, any use, reproduction or dissemination of this transmission is
strictly prohibited. If you are not the intended recipient, please
immediately notify the sender by reply e-mail or phone and delete this
message and its attachments, if any.”
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 67631 bytes
Desc: not available
URL:
From nilesh.kokane at mindastoneridge.com Sat Aug 2 15:10:59 2014
From: nilesh.kokane at mindastoneridge.com (Nilesh Kokane)
Date: Sat, 2 Aug 2014 17:40:59 +0530
Subject: [Development] bitbake meta-toolchain error
In-Reply-To: <45389886.XWi926jlrp@comet>
References:
<45389886.XWi926jlrp@comet>
Message-ID:
Hi Thomas,
Thanks for your valuable reply
EGL "thinks" (as in defines) it's a framebuffer build, Qt tries to build the
XCB plugin .. shouldn't happen when removing x11 from distro_features.
I see, but i read that i need to modify the “eglvivante.h” as header files
are not set appropriately when you compile Qt with XCB support.Can you
specify what exactly to alter to counteract on the issue
Have you 'bitbake'ed before adding DISTRO_FREATURES_remove ... ?
If so consider to start over with a fresh build because it might be a bit
hard to get rid of all X11 traces.
Yes I tried both the ways of bitbake , adding DISTRO_FREATURES_remove
DISTRO_FREATURES_remove while present in the local.conf it fails at the
last stage of do_rootfs.The logs are posted here
http://pastebin.com/QFu2Rw6G
You should go into meta-qt5, remove all "-silent" ... no clue why a managed
build system would want to have "-silent" ..
Can you specify which file in the meta-qt5 should be altered to remove
-silent
Please if you can have a look on logs and suggest me.
Thanks
Nilesh Kokane
On Sat, Aug 2, 2014 at 12:05 PM, wrote:
> EGL "thinks" (as in defines) it's a framebuffer build, Qt tries to build
> the
> XCB plugin .. shouldn't happen when removing x11 from distro_features.
>
> Have you 'bitbake'ed before adding DISTRO_FREATURES_remove ... ?
> If so consider to start over with a fresh build because it might be a bit
> hard to get rid of all X11 traces.
>
> You should go into meta-qt5, remove all "-silent" ... no clue why a managed
> build system would want to have "-silent" ..
>
> If the errors persists also add the log for configure.
>
>
> On Friday, August 01, 2014 02:49:55 PM Nilesh Kokane wrote:
> > Hello,
> >
> >
> >
> > I followed
> >
> http://wiki.wandboard.org/index.php/Building_Qt5_using_yocto_on_Wandboard
> > (newly added)
> >
> >
> > The DISTRO_FEATURES_remove = "x11 wayland" is removed from the local.conf
> >
> >
> > And after giving the bitbake core-image-minimal I'm logged with the
> errors
> > as posted on pastebin http://pastebin.com/hsMhT9f8
> >
> >
> >
> >
> > ERROR: Function failed: do_compile (log file is located at
> >
> /home/minda/bin/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-mx6-pok
> > y-linux-gnueabi/qtbase/5.2.1-r0/temp/log.do_compile.28369) ERROR:
> Logfile of
> > failure stored in:
> >
> /home/minda/bin/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-mx6-pok
> > y-linux-gnueabi/qtbase/5.2.1-r0/temp/log.do_compile.28369
> >
> >
> >
> > ERROR: Task 655
> > (/home/minda/bin/fsl-community-bsp/sources/meta-qt5/recipes-qt/qt5/
> > qtbase_5.2.1.bb, do_compile) failed with exit code '1'
> >
> >
> >
> >
> >
> > can anyone suggest.
>
>
--
Thanks
--
“The contents of this e-mail message and any attachments are confidential
and are intended solely for addressee. The information may also be legally
privileged. This transmission is sent in trust, for the sole purpose of
delivery to the intended recipient. If you have received this transmission
in error, any use, reproduction or dissemination of this transmission is
strictly prohibited. If you are not the intended recipient, please
immediately notify the sender by reply e-mail or phone and delete this
message and its attachments, if any.”
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 67631 bytes
Desc: not available
URL:
From mail at milianw.de Sat Aug 2 15:36:01 2014
From: mail at milianw.de (Milian Wolff)
Date: Sat, 02 Aug 2014 14:36:01 +0200
Subject: [Development] QtWebChannel and the Feature Freeze
In-Reply-To: <3040123.c9iaE0EqdJ@tjmaciei-mobl4>
References: <6698988.IdlkBBqK3C@milian-kdab2>
<3040123.c9iaE0EqdJ@tjmaciei-mobl4>
Message-ID: <2252052.8nSbW2lS8c@minime>
On Wednesday 30 July 2014 17:10:50 Thiago Macieira wrote:
> On Tuesday 29 July 2014 13:45:05 Milian Wolff wrote:
> > Hey all,
> >
> > What would happen if not all of the open review requests for the Qt
> > WebChannel (see [1]) repository get integrated in time for the Feature
> > Freeze? I'd appreciate if more people could review the things as needed so
> > that I can merge them as quickly as possible.
>
> That depends. If, in the opinion of the maintainer or other relevant
> experts, those pending reviews are crucial for the first release, then the
> release blocks. Those are things like API design, API review, etc.
>
> Otherwise, those changes simply get postponed to the next release.
The most important changes are now merged, I think.
> > Once these changes are in we can finally merge the Qt WebKit [2]
> > integration, without which the whole Qt WebChannel module is pretty much
> > useless to end- users (it'd still useable but requires a lot of monkey
> > coding and manual websocket boiler plate code).
> >
> > I hope that we can sort this out until the Feature Freeze. If not, can I
> > get an exception or something or would the whole module then be dropped
> > from the release plan? I hope not...
>
> As it is the first release, there is some flexibility as to how important
> those pending changes are.
>
> Can you provide a summary of the pending reviews, in priority order?
I think only the QtWebKit integration https://codereview.qt-project.org/#/c/89086/ and the addition of QtWebChannel as a Qt submodule
https://codereview.qt-project.org/#/c/90399/ are missing right now.
So I think we are on track, nice! Many thanks to everyone involved.
Bye
--
Milian Wolff
mail at milianw.de
http://milianw.de
From mail at milianw.de Sat Aug 2 15:36:01 2014
From: mail at milianw.de (Milian Wolff)
Date: Sat, 02 Aug 2014 14:36:01 +0200
Subject: [Development] QtWebChannel and the Feature Freeze
In-Reply-To: <3040123.c9iaE0EqdJ@tjmaciei-mobl4>
References: <6698988.IdlkBBqK3C@milian-kdab2>
<3040123.c9iaE0EqdJ@tjmaciei-mobl4>
Message-ID: <2252052.8nSbW2lS8c@minime>
On Wednesday 30 July 2014 17:10:50 Thiago Macieira wrote:
> On Tuesday 29 July 2014 13:45:05 Milian Wolff wrote:
> > Hey all,
> >
> > What would happen if not all of the open review requests for the Qt
> > WebChannel (see [1]) repository get integrated in time for the Feature
> > Freeze? I'd appreciate if more people could review the things as needed so
> > that I can merge them as quickly as possible.
>
> That depends. If, in the opinion of the maintainer or other relevant
> experts, those pending reviews are crucial for the first release, then the
> release blocks. Those are things like API design, API review, etc.
>
> Otherwise, those changes simply get postponed to the next release.
The most important changes are now merged, I think.
> > Once these changes are in we can finally merge the Qt WebKit [2]
> > integration, without which the whole Qt WebChannel module is pretty much
> > useless to end- users (it'd still useable but requires a lot of monkey
> > coding and manual websocket boiler plate code).
> >
> > I hope that we can sort this out until the Feature Freeze. If not, can I
> > get an exception or something or would the whole module then be dropped
> > from the release plan? I hope not...
>
> As it is the first release, there is some flexibility as to how important
> those pending changes are.
>
> Can you provide a summary of the pending reviews, in priority order?
I think only the QtWebKit integration https://codereview.qt-project.org/#/c/89086/ and the addition of QtWebChannel as a Qt submodule
https://codereview.qt-project.org/#/c/90399/ are missing right now.
So I think we are on track, nice! Many thanks to everyone involved.
Bye
--
Milian Wolff
mail at milianw.de
http://milianw.de
From perezmeyer at gmail.com Sat Aug 2 20:51:21 2014
From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer)
Date: Sat, 02 Aug 2014 14:51:21 -0300
Subject: [Development] Problem compiling qtcreator on armhf
Message-ID: <5061774.6mFCvuzPVv@luna>
Hi! I have stepped upon a problem while building qtcreator on armhf and just
on this arch.
The compiler seems to get into an infinite loop while building
src/plugins/qmldesigner/designercore/model/qmltextgenerator.cpp . The
compilation line for this is in [0].
If I compile this file with -O1 everything goes OK. I suspect it to bee a
compiler problem, but I have no idea on what to do to try and fill a bug
against the compiler.
Could you give me some hints to try to get this solved?
Kinds regards, Lisandro.
[0]
g++ -c -pipe -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -
Werror=format-security -D_FORTIFY_SOURCE=2 -fvisibility=hidden -fvisibility-
inlines-hidden -std=c++0x -Wall -W -D_REENTRANT -fPIC -
DIDE_LIBRARY_BASENAME="lib/arm-linux-gnueabihf" -DQT_CREATOR -
DQT_NO_CAST_TO_ASCII -DQT_USE_FAST_OPERATOR_PLUS -DQT_USE_FAST_CONCATENATION -
DQT_DISABLE_DEPRECATED_BEFORE=0x040900 -DQMAKE_AS_LIBRARY -
DPROPARSER_THREAD_SAFE -DPROEVALUATOR_THREAD_SAFE -DPROEVALUATOR_CUMULATIVE -
DPROEVALUATOR_SETENV -DVIEWLOGGER -DENABLE_TEXT_VIEW -
DQWEAKPOINTER_ENABLE_ARROW -DQDEBUG_IN_TESTS -DWARNINGS_IN_TESTS -
DTEST_EXPORTS -DDESIGNER_CORE_LIBRARY -DQT_NO_DEBUG -DQT_PLUGIN -DQT_QUICK_LIB
-DQT_QML_LIB -DQT_WIDGETS_LIB -DQT_SCRIPT_LIB -DQT_NETWORK_LIB -
DQT_CONCURRENT_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/lib/arm-linux-
gnueabihf/qt5/mkspecs/linux-g++ -
I/home/lisandro/qtcreator/src/plugins/qmldesigner -
I/home/lisandro/qtcreator/src/plugins/qmldesigner -
I/home/lisandro/qtcreator/share/qtcreator/qml/qmlpuppet/interfaces -
I/home/lisandro/qtcreator/share/qtcreator/qml/qmlpuppet/types -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/designercore -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/designercore/include -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/components/componentcore -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/components/importmanager -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/components/formeditor -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/components/itemlibrary -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/components/navigator -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/components/propertyeditor -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/components/stateseditor -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/components/debugview -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/components/integration -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/components/logger -
I../../../src -I/home/lisandro/qtcreator/src/libs -
I/home/lisandro/qtcreator/tools -I/home/lisandro/qtcreator/src/plugins -
I/home/lisandro/qtcreator/src/shared -
I/home/lisandro/qtcreator/src/libs/3rdparty -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/designercore -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/designercore/include -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/designercore/instances -
I/home/lisandro/qtcreator/share/qtcreator/qml/qmlpuppet/interfaces -
I/home/lisandro/qtcreator/share/qtcreator/qml/qmlpuppet/commands -
I/home/lisandro/qtcreator/share/qtcreator/qml/qmlpuppet/container -
I/home/lisandro/qtcreator/share/qtcreator/qml/qmlpuppet/types -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/components/pluginmanager -
isystem /usr/include/arm-linux-gnueabihf/qt5 -isystem /usr/include/arm-linux-
gnueabihf/qt5/QtQuick -isystem /usr/include/arm-linux-gnueabihf/qt5/QtQml -
isystem /usr/include/arm-linux-gnueabihf/qt5/QtWidgets -isystem
/usr/include/arm-linux-gnueabihf/qt5/QtScript -isystem /usr/include/arm-linux-
gnueabihf/qt5/QtNetwork -isystem /usr/include/arm-linux-
gnueabihf/qt5/QtConcurrent -isystem /usr/include/arm-linux-gnueabihf/qt5/QtGui
-isystem /usr/include/arm-linux-gnueabihf/qt5/QtCore -I.moc/release-shared -
I.uic -I. -o .obj/release-shared/qmltextgenerator.o
/home/lisandro/qtcreator/src/plugins/qmldesigner/designercore/model/qmltextgenerator.cpp
--
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL:
From perezmeyer at gmail.com Sat Aug 2 20:51:21 2014
From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer)
Date: Sat, 02 Aug 2014 14:51:21 -0300
Subject: [Development] Problem compiling qtcreator on armhf
Message-ID: <5061774.6mFCvuzPVv@luna>
Hi! I have stepped upon a problem while building qtcreator on armhf and just
on this arch.
The compiler seems to get into an infinite loop while building
src/plugins/qmldesigner/designercore/model/qmltextgenerator.cpp . The
compilation line for this is in [0].
If I compile this file with -O1 everything goes OK. I suspect it to bee a
compiler problem, but I have no idea on what to do to try and fill a bug
against the compiler.
Could you give me some hints to try to get this solved?
Kinds regards, Lisandro.
[0]
g++ -c -pipe -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -
Werror=format-security -D_FORTIFY_SOURCE=2 -fvisibility=hidden -fvisibility-
inlines-hidden -std=c++0x -Wall -W -D_REENTRANT -fPIC -
DIDE_LIBRARY_BASENAME="lib/arm-linux-gnueabihf" -DQT_CREATOR -
DQT_NO_CAST_TO_ASCII -DQT_USE_FAST_OPERATOR_PLUS -DQT_USE_FAST_CONCATENATION -
DQT_DISABLE_DEPRECATED_BEFORE=0x040900 -DQMAKE_AS_LIBRARY -
DPROPARSER_THREAD_SAFE -DPROEVALUATOR_THREAD_SAFE -DPROEVALUATOR_CUMULATIVE -
DPROEVALUATOR_SETENV -DVIEWLOGGER -DENABLE_TEXT_VIEW -
DQWEAKPOINTER_ENABLE_ARROW -DQDEBUG_IN_TESTS -DWARNINGS_IN_TESTS -
DTEST_EXPORTS -DDESIGNER_CORE_LIBRARY -DQT_NO_DEBUG -DQT_PLUGIN -DQT_QUICK_LIB
-DQT_QML_LIB -DQT_WIDGETS_LIB -DQT_SCRIPT_LIB -DQT_NETWORK_LIB -
DQT_CONCURRENT_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/lib/arm-linux-
gnueabihf/qt5/mkspecs/linux-g++ -
I/home/lisandro/qtcreator/src/plugins/qmldesigner -
I/home/lisandro/qtcreator/src/plugins/qmldesigner -
I/home/lisandro/qtcreator/share/qtcreator/qml/qmlpuppet/interfaces -
I/home/lisandro/qtcreator/share/qtcreator/qml/qmlpuppet/types -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/designercore -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/designercore/include -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/components/componentcore -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/components/importmanager -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/components/formeditor -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/components/itemlibrary -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/components/navigator -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/components/propertyeditor -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/components/stateseditor -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/components/debugview -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/components/integration -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/components/logger -
I../../../src -I/home/lisandro/qtcreator/src/libs -
I/home/lisandro/qtcreator/tools -I/home/lisandro/qtcreator/src/plugins -
I/home/lisandro/qtcreator/src/shared -
I/home/lisandro/qtcreator/src/libs/3rdparty -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/designercore -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/designercore/include -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/designercore/instances -
I/home/lisandro/qtcreator/share/qtcreator/qml/qmlpuppet/interfaces -
I/home/lisandro/qtcreator/share/qtcreator/qml/qmlpuppet/commands -
I/home/lisandro/qtcreator/share/qtcreator/qml/qmlpuppet/container -
I/home/lisandro/qtcreator/share/qtcreator/qml/qmlpuppet/types -
I/home/lisandro/qtcreator/src/plugins/qmldesigner/components/pluginmanager -
isystem /usr/include/arm-linux-gnueabihf/qt5 -isystem /usr/include/arm-linux-
gnueabihf/qt5/QtQuick -isystem /usr/include/arm-linux-gnueabihf/qt5/QtQml -
isystem /usr/include/arm-linux-gnueabihf/qt5/QtWidgets -isystem
/usr/include/arm-linux-gnueabihf/qt5/QtScript -isystem /usr/include/arm-linux-
gnueabihf/qt5/QtNetwork -isystem /usr/include/arm-linux-
gnueabihf/qt5/QtConcurrent -isystem /usr/include/arm-linux-gnueabihf/qt5/QtGui
-isystem /usr/include/arm-linux-gnueabihf/qt5/QtCore -I.moc/release-shared -
I.uic -I. -o .obj/release-shared/qmltextgenerator.o
/home/lisandro/qtcreator/src/plugins/qmldesigner/designercore/model/qmltextgenerator.cpp
--
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL:
From perezmeyer at gmail.com Sat Aug 2 20:53:10 2014
From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer)
Date: Sat, 02 Aug 2014 14:53:10 -0300
Subject: [Development] Problem compiling qtcreator on armhf
In-Reply-To: <5061774.6mFCvuzPVv@luna>
References: <5061774.6mFCvuzPVv@luna>
Message-ID: <127928028.WGqQBLDp7e@luna>
On Saturday 02 August 2014 14:51:21 Lisandro Damián Nicanor Pérez Meyer wrote:
> Hi! I have stepped upon a problem while building qtcreator on armhf and just
> on this arch.
>
> The compiler seems to get into an infinite loop while building
> src/plugins/qmldesigner/designercore/model/qmltextgenerator.cpp . The
> compilation line for this is in [0].
>
> If I compile this file with -O1 everything goes OK. I suspect it to bee a
> compiler problem, but I have no idea on what to do to try and fill a bug
> against the compiler.
>
> Could you give me some hints to try to get this solved?
Just for the record, I'm also seeing this while compiling:
/home/lisandro/qtcreator/src/plugins/qmldesigner/designercore/model/qmltextgenerator.cpp:
In member function 'QString
QmlDesigner::Internal::QmlTextGenerator::toQml(const
QmlDesigner::AbstractProperty&, int) const':
/home/lisandro/qtcreator/src/plugins/qmldesigner/designercore/model/qmltextgenerator.cpp:130:13:
warning: case value '38' not in enumerated type 'QVariant::Type' [-Wswitch]
case static_cast(QMetaType::Float):
--
8: Si un archivo ha pasado a la "Papelera de Reciclaje"
* Ud tiene una carpeta llamada "Papelera de Reciclaje"
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL:
From thiago.macieira at intel.com Sat Aug 2 19:22:54 2014
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 02 Aug 2014 13:22:54 -0300
Subject: [Development] bitbake meta-toolchain error
In-Reply-To:
References:
Message-ID: <3953886.GkDIVWslFL@tjmaciei-mobl4>
On Friday 01 August 2014 14:49:55 Nilesh Kokane wrote:
> I followed
> http://wiki.wandboard.org/index.php/Building_Qt5_using_yocto_on_Wandboard
> (newly added)
Hi Nilesh
Your question is not about development of Qt itself. Please use the Qt
interest mailing list or a Yocto mailing list, since your problem is about
using bitbake and the yocto recipes.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
From thiago.macieira at intel.com Sat Aug 2 19:21:20 2014
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 02 Aug 2014 13:21:20 -0300
Subject: [Development] [docs/c++] How do we deal with the special member
functions (copy/move ctor/assignment operator, dtor, default ctor)
In-Reply-To: <201408012316.40275.marc.mutz@kdab.com>
References: <201408012316.40275.marc.mutz@kdab.com>
Message-ID: <3783897.zvvUg1BiLp@tjmaciei-mobl4>
On Friday 01 August 2014 23:16:40 Marc Mutz wrote:
> That leaves the question how to deal with the documentation for these
> implicit members.
Why do we have to document them in the first place? I hate having to write
documentation for a destructor that simply says "frees resources associated
with this object". That much is obvious: any self-respecting destructor will
do that and the same applies to copy and move constructors.
What we really want is to document which objects are copyable and which ones
aren't. And that is very simple: any object with Q_DISABLE_COPY is not
copyable, (almost) everything else is.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
From thiago.macieira at intel.com Sat Aug 2 19:19:16 2014
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 02 Aug 2014 13:19:16 -0300
Subject: [Development] Relative paths in EXAMPLE_FILES in .pro files
In-Reply-To: <53DBA7FC.5070600@basyskom.com>
References: <53DBA7FC.5070600@basyskom.com>
Message-ID: <36078478.Agox8kLvH2@tjmaciei-mobl4>
On Friday 01 August 2014 16:45:16 Sumedha Widyadharma wrote:
> Hi,
>
> This seems to be forbidden in a .pro file:
>
> EXAMPLE_FILES += ../some/file
>
> what is the rationale behind not allowing this?
Why is it forbidden?
> It is silently dropped, you have to enable CONFIG+=check_examples to get
> a notice about this. Why is that?
About what?
You can assign any value to any variable you want in qmake. Whether you make
use of the variable or not, it's up to you.
> Shouldn't it always warn the user?
About what?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
From thiago.macieira at intel.com Sat Aug 2 19:18:24 2014
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 02 Aug 2014 13:18:24 -0300
Subject: [Development] QOpenGLWidget vs. QGLWidget
In-Reply-To: <53DB2E4C.7040904@verosoftware.com>
References: <53DA26DB.3030805@verosoftware.com>
<53DB2E4C.7040904@verosoftware.com>
Message-ID: <1604150.A5C1mWRWem@tjmaciei-mobl4>
On Friday 01 August 2014 06:06:06 Yves Bailly wrote:
> On 31/07/2014 20:03, Agocs Laszlo wrote:
> > Yes, setViewport() will continue to work with QOpenGLWidget too.
>
> Great! :-)
>
> > Note that all this does not mean existing code has to migrate away from
> > QGLWidget.>
> > It is not going to disappear. If it works, just keep using it.
>
> Fine, however QGLWidget's status moving to "deprecated" is the first step
> on the road to "obsolete", then sooner or later "removed"...
For us, deprecated == obsolete and removed == Qt 6.
> So I guess
> new codes should use QOpenGLWidget, while old ones should migrate little
> by little.
Right, that's a good idea.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
From thiago.macieira at intel.com Sat Aug 2 19:17:02 2014
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 02 Aug 2014 13:17:02 -0300
Subject: [Development] Any C++11-capable compiler for Windows CE?
In-Reply-To: <53D9DF7E.6080903@kdab.com>
References: <2536466.FIkxHD6SGX@tjmaciei-mobl4> <53D9DF7E.6080903@kdab.com>
Message-ID: <3794091.B528JqgkQA@tjmaciei-mobl4>
On Thursday 31 July 2014 08:17:34 Andreas Holzammer wrote:
> yes in recent Windows CE Versions either the Visual Studio 2012 or
> Visual Studio 2013[1] compiler is beeing used, which have some C++11
> features. But yes this applies to Windows Embedded 2013 and above,
> most systems which are used nowerdays use Windows Embedded Compact 7
> which just has the Visual Studio 2008 compiler. To be honest I did not
> had yet a Windows Embedded Compact 2013 hardware in my hands, so this
> is more a question in dropping support for Windows Embedded Compact 7,
> and I think that would be too early.
Thanks for the answer. It's not what I'd would have preferred to hear, but
it's an answer alright.
Note: we are allowed to add C++11-only features, so long as Qt continues to
build. For example, the new QThread::makeThread will most likely require
lambdas and std::function.
In fact, I encourage people to add new, convenience API that is C++11 only.
Like Marc says, "C++98 costs more" and we want people to force their vendors
to provide support.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
From thiago.macieira at intel.com Sat Aug 2 19:14:18 2014
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 02 Aug 2014 13:14:18 -0300
Subject: [Development] QZipReader and QZipWriter
In-Reply-To: <20140731083056.GC4927@ugly.fritz.box>
References:
<1727845.pJKJQYuIsM@tjmaciei-mobl4>
<20140731083056.GC4927@ugly.fritz.box>
Message-ID: <21985962.1jl2FyDo8B@tjmaciei-mobl4>
On Thursday 31 July 2014 10:30:56 Oswald Buddenhagen wrote:
> On Wed, Jul 30, 2014 at 05:08:15PM -0700, Thiago Macieira wrote:
> > On Monday 28 July 2014 11:08:59 Olivier Goffart wrote:
> > > Otherwise, you can also use the KArchive module part of KDE Frameworks
> > > http://api.kde.org/frameworks-api/frameworks5-apidocs/karchive/html/inde
> > > x.html>
> > The existence of KArchive basically blocks a new module in Qt that does
> > this, unless this new module has relevant new functionality or is
> > considerably less resource-demanding than KArchive.
>
> you wish.
>
> but in reality, as long as there is no competing free product that permits
> digia to satisfy its (l)gpl-averse customers as well, the qt project will
> welcome such an effort, even if i personally wouldn't recommend
> duplicating the work.
True, but it will do so like you said: recommending against the duplicated
effort.
And to be honest, while convenient, this is not a must-have feature. With my
OSS hat on, I would say (L)GPL-averse customers could be served right by their
aversion by having one fewer solution.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
From perezmeyer at gmail.com Sat Aug 2 20:53:10 2014
From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer)
Date: Sat, 02 Aug 2014 14:53:10 -0300
Subject: [Development] Problem compiling qtcreator on armhf
In-Reply-To: <5061774.6mFCvuzPVv@luna>
References: <5061774.6mFCvuzPVv@luna>
Message-ID: <127928028.WGqQBLDp7e@luna>
On Saturday 02 August 2014 14:51:21 Lisandro Damián Nicanor Pérez Meyer wrote:
> Hi! I have stepped upon a problem while building qtcreator on armhf and just
> on this arch.
>
> The compiler seems to get into an infinite loop while building
> src/plugins/qmldesigner/designercore/model/qmltextgenerator.cpp . The
> compilation line for this is in [0].
>
> If I compile this file with -O1 everything goes OK. I suspect it to bee a
> compiler problem, but I have no idea on what to do to try and fill a bug
> against the compiler.
>
> Could you give me some hints to try to get this solved?
Just for the record, I'm also seeing this while compiling:
/home/lisandro/qtcreator/src/plugins/qmldesigner/designercore/model/qmltextgenerator.cpp:
In member function 'QString
QmlDesigner::Internal::QmlTextGenerator::toQml(const
QmlDesigner::AbstractProperty&, int) const':
/home/lisandro/qtcreator/src/plugins/qmldesigner/designercore/model/qmltextgenerator.cpp:130:13:
warning: case value '38' not in enumerated type 'QVariant::Type' [-Wswitch]
case static_cast(QMetaType::Float):
--
8: Si un archivo ha pasado a la "Papelera de Reciclaje"
* Ud tiene una carpeta llamada "Papelera de Reciclaje"
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL:
From thiago.macieira at intel.com Sat Aug 2 19:22:54 2014
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 02 Aug 2014 13:22:54 -0300
Subject: [Development] bitbake meta-toolchain error
In-Reply-To:
References:
Message-ID: <3953886.GkDIVWslFL@tjmaciei-mobl4>
On Friday 01 August 2014 14:49:55 Nilesh Kokane wrote:
> I followed
> http://wiki.wandboard.org/index.php/Building_Qt5_using_yocto_on_Wandboard
> (newly added)
Hi Nilesh
Your question is not about development of Qt itself. Please use the Qt
interest mailing list or a Yocto mailing list, since your problem is about
using bitbake and the yocto recipes.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
From thiago.macieira at intel.com Sat Aug 2 19:21:20 2014
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 02 Aug 2014 13:21:20 -0300
Subject: [Development] [docs/c++] How do we deal with the special member
functions (copy/move ctor/assignment operator, dtor, default ctor)
In-Reply-To: <201408012316.40275.marc.mutz@kdab.com>
References: <201408012316.40275.marc.mutz@kdab.com>
Message-ID: <3783897.zvvUg1BiLp@tjmaciei-mobl4>
On Friday 01 August 2014 23:16:40 Marc Mutz wrote:
> That leaves the question how to deal with the documentation for these
> implicit members.
Why do we have to document them in the first place? I hate having to write
documentation for a destructor that simply says "frees resources associated
with this object". That much is obvious: any self-respecting destructor will
do that and the same applies to copy and move constructors.
What we really want is to document which objects are copyable and which ones
aren't. And that is very simple: any object with Q_DISABLE_COPY is not
copyable, (almost) everything else is.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
From thiago.macieira at intel.com Sat Aug 2 19:19:16 2014
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 02 Aug 2014 13:19:16 -0300
Subject: [Development] Relative paths in EXAMPLE_FILES in .pro files
In-Reply-To: <53DBA7FC.5070600@basyskom.com>
References: <53DBA7FC.5070600@basyskom.com>
Message-ID: <36078478.Agox8kLvH2@tjmaciei-mobl4>
On Friday 01 August 2014 16:45:16 Sumedha Widyadharma wrote:
> Hi,
>
> This seems to be forbidden in a .pro file:
>
> EXAMPLE_FILES += ../some/file
>
> what is the rationale behind not allowing this?
Why is it forbidden?
> It is silently dropped, you have to enable CONFIG+=check_examples to get
> a notice about this. Why is that?
About what?
You can assign any value to any variable you want in qmake. Whether you make
use of the variable or not, it's up to you.
> Shouldn't it always warn the user?
About what?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
From thiago.macieira at intel.com Sat Aug 2 19:18:24 2014
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 02 Aug 2014 13:18:24 -0300
Subject: [Development] QOpenGLWidget vs. QGLWidget
In-Reply-To: <53DB2E4C.7040904@verosoftware.com>
References: <53DA26DB.3030805@verosoftware.com>
<53DB2E4C.7040904@verosoftware.com>
Message-ID: <1604150.A5C1mWRWem@tjmaciei-mobl4>
On Friday 01 August 2014 06:06:06 Yves Bailly wrote:
> On 31/07/2014 20:03, Agocs Laszlo wrote:
> > Yes, setViewport() will continue to work with QOpenGLWidget too.
>
> Great! :-)
>
> > Note that all this does not mean existing code has to migrate away from
> > QGLWidget.>
> > It is not going to disappear. If it works, just keep using it.
>
> Fine, however QGLWidget's status moving to "deprecated" is the first step
> on the road to "obsolete", then sooner or later "removed"...
For us, deprecated == obsolete and removed == Qt 6.
> So I guess
> new codes should use QOpenGLWidget, while old ones should migrate little
> by little.
Right, that's a good idea.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
From thiago.macieira at intel.com Sat Aug 2 19:17:02 2014
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 02 Aug 2014 13:17:02 -0300
Subject: [Development] Any C++11-capable compiler for Windows CE?
In-Reply-To: <53D9DF7E.6080903@kdab.com>
References: <2536466.FIkxHD6SGX@tjmaciei-mobl4> <53D9DF7E.6080903@kdab.com>
Message-ID: <3794091.B528JqgkQA@tjmaciei-mobl4>
On Thursday 31 July 2014 08:17:34 Andreas Holzammer wrote:
> yes in recent Windows CE Versions either the Visual Studio 2012 or
> Visual Studio 2013[1] compiler is beeing used, which have some C++11
> features. But yes this applies to Windows Embedded 2013 and above,
> most systems which are used nowerdays use Windows Embedded Compact 7
> which just has the Visual Studio 2008 compiler. To be honest I did not
> had yet a Windows Embedded Compact 2013 hardware in my hands, so this
> is more a question in dropping support for Windows Embedded Compact 7,
> and I think that would be too early.
Thanks for the answer. It's not what I'd would have preferred to hear, but
it's an answer alright.
Note: we are allowed to add C++11-only features, so long as Qt continues to
build. For example, the new QThread::makeThread will most likely require
lambdas and std::function.
In fact, I encourage people to add new, convenience API that is C++11 only.
Like Marc says, "C++98 costs more" and we want people to force their vendors
to provide support.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
From thiago.macieira at intel.com Sat Aug 2 19:14:18 2014
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 02 Aug 2014 13:14:18 -0300
Subject: [Development] QZipReader and QZipWriter
In-Reply-To: <20140731083056.GC4927@ugly.fritz.box>
References:
<1727845.pJKJQYuIsM@tjmaciei-mobl4>
<20140731083056.GC4927@ugly.fritz.box>
Message-ID: <21985962.1jl2FyDo8B@tjmaciei-mobl4>
On Thursday 31 July 2014 10:30:56 Oswald Buddenhagen wrote:
> On Wed, Jul 30, 2014 at 05:08:15PM -0700, Thiago Macieira wrote:
> > On Monday 28 July 2014 11:08:59 Olivier Goffart wrote:
> > > Otherwise, you can also use the KArchive module part of KDE Frameworks
> > > http://api.kde.org/frameworks-api/frameworks5-apidocs/karchive/html/inde
> > > x.html>
> > The existence of KArchive basically blocks a new module in Qt that does
> > this, unless this new module has relevant new functionality or is
> > considerably less resource-demanding than KArchive.
>
> you wish.
>
> but in reality, as long as there is no competing free product that permits
> digia to satisfy its (l)gpl-averse customers as well, the qt project will
> welcome such an effort, even if i personally wouldn't recommend
> duplicating the work.
True, but it will do so like you said: recommending against the duplicated
effort.
And to be honest, while convenient, this is not a must-have feature. With my
OSS hat on, I would say (L)GPL-averse customers could be served right by their
aversion by having one fewer solution.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
From gunnar.roth at gmx.de Sun Aug 3 01:02:22 2014
From: gunnar.roth at gmx.de (Gunnar Roth)
Date: Sun, 3 Aug 2014 00:02:22 +0200
Subject: [Development] Any C++11-capable compiler for Windows CE?
In-Reply-To: <3794091.B528JqgkQA@tjmaciei-mobl4>
References: <2536466.FIkxHD6SGX@tjmaciei-mobl4> <53D9DF7E.6080903@kdab.com>
<3794091.B528JqgkQA@tjmaciei-mobl4>
Message-ID: <5646EB21-3DFE-49FD-ABAE-CB382E0A9957@gmx.de>
Hi,
i would like to add some information to this topic.
"Now updated to support both Visual Studio 2013 and Visual Studio 2012, „
just means that you can use the IDE for developing , but the compiler used for compiling
is still the compiler from you device sdks. In wec2013 MS started to put the compiler into the sdks in contrast to wec 7 and before, where the compiler from visual studio was used. 2008 for wec 7 and ce6, vs 2005 for ce 5. Before this there was a thing called eve, bu this leads to far ;-) For wec 7 there was a trick from adeneo to use the compiler from platform builder , which has the advantage over vs2008 to be able to generate armv6 and armv7 code.
The compiler in a wec 2013 sdk, is an older version of the vs2012 compiler. It was recently updated by MS with the June update to fix some internal compiler error we happen to face when building webkit from qt 4.8.5.But the version number of l.exe ist still lower. This internal error was a problem with inlining we could workaround with force noinline. The statement MS gave us concerning the compiler was that they will not update the compiler to any newer version, because of heavy impact on testing. One ce version will stay with a compiler version forever.
Actually we managed to use the vs2013 compiler to build ffmpeg ( because of the c99 features only vs2013 compiler supports) for wec2013 as we did use CeGCC 0.59.1 based on gcc4.4 for this on ce 6 but this old compiler cannot generate the new EABI + THUMB2 CODE which is needed for Wec2013. We did not try with C++ code yet, but that would also not give full advanced c++11 features because we still have to use the stl etc. from the wec2013 sdks, which is of course different from the stl in vs2013 for winrt. which would be the only other arm platform.
Forcing MS to support c+11 for wec 7 is hopeless, i assure you.
Right now qt 4 support ce 5, ce 6 and ce 7. We did our own port to wec2013, which was not too hard to do. Most of things are removing ce combat layer stuff, as wec2013 as a much more complete c-runtime, which is now clashing with the ce compat functions.
I also did a port of qt 5.3.1 to wec 2013, but this was a lot harder to do for several reasons, having about 13 patches and a need to modify the standard wec2013 image ( adding dnsapi and shellsdk and copying some headers from ce 6 to satisfy qt)
I even managed to support ce 6 in qt 5.3.1 with some small additional patches ( but no support for qmL and quick 2, only quick1)
Regards,
Gunnar
> Am 02.08.2014 um 18:17 schrieb Thiago Macieira :
>
> On Thursday 31 July 2014 08:17:34 Andreas Holzammer wrote:
>> yes in recent Windows CE Versions either the Visual Studio 2012 or
>> Visual Studio 2013[1] compiler is beeing used, which have some C++11
>> features. But yes this applies to Windows Embedded 2013 and above,
>> most systems which are used nowerdays use Windows Embedded Compact 7
>> which just has the Visual Studio 2008 compiler. To be honest I did not
>> had yet a Windows Embedded Compact 2013 hardware in my hands, so this
>> is more a question in dropping support for Windows Embedded Compact 7,
>> and I think that would be too early.
>
> Thanks for the answer. It's not what I'd would have preferred to hear, but
> it's an answer alright.
>
> Note: we are allowed to add C++11-only features, so long as Qt continues to
> build. For example, the new QThread::makeThread will most likely require
> lambdas and std::function.
>
> In fact, I encourage people to add new, convenience API that is C++11 only.
> Like Marc says, "C++98 costs more" and we want people to force their vendors
> to provide support.
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
From gunnar.roth at gmx.de Sun Aug 3 01:02:22 2014
From: gunnar.roth at gmx.de (Gunnar Roth)
Date: Sun, 3 Aug 2014 00:02:22 +0200
Subject: [Development] Any C++11-capable compiler for Windows CE?
In-Reply-To: <3794091.B528JqgkQA@tjmaciei-mobl4>
References: <2536466.FIkxHD6SGX@tjmaciei-mobl4> <53D9DF7E.6080903@kdab.com>
<3794091.B528JqgkQA@tjmaciei-mobl4>
Message-ID: <5646EB21-3DFE-49FD-ABAE-CB382E0A9957@gmx.de>
Hi,
i would like to add some information to this topic.
"Now updated to support both Visual Studio 2013 and Visual Studio 2012, „
just means that you can use the IDE for developing , but the compiler used for compiling
is still the compiler from you device sdks. In wec2013 MS started to put the compiler into the sdks in contrast to wec 7 and before, where the compiler from visual studio was used. 2008 for wec 7 and ce6, vs 2005 for ce 5. Before this there was a thing called eve, bu this leads to far ;-) For wec 7 there was a trick from adeneo to use the compiler from platform builder , which has the advantage over vs2008 to be able to generate armv6 and armv7 code.
The compiler in a wec 2013 sdk, is an older version of the vs2012 compiler. It was recently updated by MS with the June update to fix some internal compiler error we happen to face when building webkit from qt 4.8.5.But the version number of l.exe ist still lower. This internal error was a problem with inlining we could workaround with force noinline. The statement MS gave us concerning the compiler was that they will not update the compiler to any newer version, because of heavy impact on testing. One ce version will stay with a compiler version forever.
Actually we managed to use the vs2013 compiler to build ffmpeg ( because of the c99 features only vs2013 compiler supports) for wec2013 as we did use CeGCC 0.59.1 based on gcc4.4 for this on ce 6 but this old compiler cannot generate the new EABI + THUMB2 CODE which is needed for Wec2013. We did not try with C++ code yet, but that would also not give full advanced c++11 features because we still have to use the stl etc. from the wec2013 sdks, which is of course different from the stl in vs2013 for winrt. which would be the only other arm platform.
Forcing MS to support c+11 for wec 7 is hopeless, i assure you.
Right now qt 4 support ce 5, ce 6 and ce 7. We did our own port to wec2013, which was not too hard to do. Most of things are removing ce combat layer stuff, as wec2013 as a much more complete c-runtime, which is now clashing with the ce compat functions.
I also did a port of qt 5.3.1 to wec 2013, but this was a lot harder to do for several reasons, having about 13 patches and a need to modify the standard wec2013 image ( adding dnsapi and shellsdk and copying some headers from ce 6 to satisfy qt)
I even managed to support ce 6 in qt 5.3.1 with some small additional patches ( but no support for qmL and quick 2, only quick1)
Regards,
Gunnar
> Am 02.08.2014 um 18:17 schrieb Thiago Macieira :
>
> On Thursday 31 July 2014 08:17:34 Andreas Holzammer wrote:
>> yes in recent Windows CE Versions either the Visual Studio 2012 or
>> Visual Studio 2013[1] compiler is beeing used, which have some C++11
>> features. But yes this applies to Windows Embedded 2013 and above,
>> most systems which are used nowerdays use Windows Embedded Compact 7
>> which just has the Visual Studio 2008 compiler. To be honest I did not
>> had yet a Windows Embedded Compact 2013 hardware in my hands, so this
>> is more a question in dropping support for Windows Embedded Compact 7,
>> and I think that would be too early.
>
> Thanks for the answer. It's not what I'd would have preferred to hear, but
> it's an answer alright.
>
> Note: we are allowed to add C++11-only features, so long as Qt continues to
> build. For example, the new QThread::makeThread will most likely require
> lambdas and std::function.
>
> In fact, I encourage people to add new, convenience API that is C++11 only.
> Like Marc says, "C++98 costs more" and we want people to force their vendors
> to provide support.
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
From gunnar.roth at gmx.de Sun Aug 3 01:08:28 2014
From: gunnar.roth at gmx.de (Gunnar Roth)
Date: Sun, 3 Aug 2014 00:08:28 +0200
Subject: [Development] QZipReader and QZipWriter
In-Reply-To: <21985962.1jl2FyDo8B@tjmaciei-mobl4>
References:
<1727845.pJKJQYuIsM@tjmaciei-mobl4>
<20140731083056.GC4927@ugly.fritz.box>
<21985962.1jl2FyDo8B@tjmaciei-mobl4>
Message-ID: <213CA41A-1DF5-44AE-B93F-3FBB19943F39@gmx.de>
> Am 02.08.2014 um 18:14 schrieb Thiago Macieira :
>
>
> And to be honest, while convenient, this is not a must-have feature. With my
> OSS hat on, I would say (L)GPL-averse customers could be served right by their
> aversion by having one fewer solution.
> --
As someone who has a qt commercial license for some years now and advocated the use of qt commercial internally,
so we have bought nearly about some dozen licenses, this is interesting to hear , what kind of appreciation we get for paying thousands of euros each year. Nice…no so.
regards,
Gunnar
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From gunnar.roth at gmx.de Sun Aug 3 01:08:28 2014
From: gunnar.roth at gmx.de (Gunnar Roth)
Date: Sun, 3 Aug 2014 00:08:28 +0200
Subject: [Development] QZipReader and QZipWriter
In-Reply-To: <21985962.1jl2FyDo8B@tjmaciei-mobl4>
References:
<1727845.pJKJQYuIsM@tjmaciei-mobl4>
<20140731083056.GC4927@ugly.fritz.box>
<21985962.1jl2FyDo8B@tjmaciei-mobl4>
Message-ID: <213CA41A-1DF5-44AE-B93F-3FBB19943F39@gmx.de>
> Am 02.08.2014 um 18:14 schrieb Thiago Macieira :
>
>
> And to be honest, while convenient, this is not a must-have feature. With my
> OSS hat on, I would say (L)GPL-averse customers could be served right by their
> aversion by having one fewer solution.
> --
As someone who has a qt commercial license for some years now and advocated the use of qt commercial internally,
so we have bought nearly about some dozen licenses, this is interesting to hear , what kind of appreciation we get for paying thousands of euros each year. Nice…no so.
regards,
Gunnar
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jake.petroules at petroules.com Sun Aug 3 01:39:00 2014
From: jake.petroules at petroules.com (Jake Petroules)
Date: Sat, 2 Aug 2014 18:39:00 -0400
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To:
References: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
<53DBF1F5.7030401@tungware.se>
<4BF629EA-C68A-434B-A042-27EA671D92FF@petroules.com>
Message-ID: <4A3F9CEC-5459-4F42-9426-875D0D8B7E69@petroules.com>
On 2014-08-02, at 05:04 AM, Adam Strzelecki wrote:
>> Please don't exaggerate the performance implications of copying a few frameworks on the first build (…)
>
> This can be done, but discussion is going off-topic.
>
> Let us try first to move Qt frameworks to use @rpath & remove some unnecessary operations while keeping current workflow with minimal changes to the code. Therefore I hereby propose to (1) keep rpath to Qt SDK in built app executable, (2) not copy anything on build, (3) make macdeploy modify ONLY executable removing absolute rpath (instead fixing frameworks), and (4) just copy needed frameworks and (5) optionally sign whole bundle.
>
> This will not require any wrappers, environment variables or changes in Qt Creator to run your app. Only Qmake and macdeploy need to be changed.
>
> Frankly I don't see anything wrong with keeping full path to SDK in executable when it isn't yet completely bundled. And the initial intention was to NOT touch Qt SDK modules once they are built.
>
> Once this is done & working we can follow this discussion and think what can be done next.
>
> --
> Adam
This isn't off topic at all. @rpath, copying frameworks, DYLD_ environment variables are all inseparably linked and very much part of the same discussion and overall issue. Your proposal to simply add @rpath and do nothing else has no benefits. What problem does it solve, other than deleting a bit of code from macdeployqt that currently works and will continue to work without maintenance? None. There is no point in doing it unless we go all the way and make the Qt SDK completely relocatable.
I understand you want to start by completing one objective at a time, but keep in mind each of these objectives is part of a greater overall goal. Alone, they are pointless.
>> Actually you CAN add Info.plist to bundle-less apps using the linker arguments: `-sectcreate __TEXT __info_plist Info.plist` which will embed it in the binary. All OS X APIs handle this transparently. Though, LSEnvironment is not a good solution for the problem we are trying to solve here.
>
> I was expecting that ;) But wasn't your intention to not modify binary once it has been built and not hardcode any paths into it?
Yes, which is why I said LSEnvironment is not a good solution.
>> Why would you do any of these things?
>
> Because you dislike adding absolute rpath to Qt SDK in built binary during dev process.
All of those things involve hardcoding absolute paths *somewhere*. There should be no absolute paths *anywhere* except environment variables that are automatically set per-session.
>> "Inject"? DYLD_LIBRARY_PATH is an environment variable. You simply set it in the process's environment before spawning.
>
> It is not so simple, first of all as you shown it works only from console, but if you launch it via GUI you need this variable to be set in launchd. As ~/.launchd.conf doesn't work anymore since Lion only permanent solution is to use /etc/launchd-user.conf which require admin to create/modify.
>
> Secondly DYLD_LIBRARY_PATH has strong security implications as the path is searched BEFORE default locations. So it does in fact let you inject/replace libraries. This is the reason dyld disables that for any process running under root account.
>
> man dyld
>
> DYLD_LIBRARY_PATH
>
> The dynamic linker searches these directories BEFORE it searches the default locations for libraries.
>
> What might be considered there is DYLD_FALLBACK_FRAMEWORK_PATH.
This is another excuse - there are no real security implications in practice. If you're even thinking about this, your machine has already been compromised and you no longer own it. Remember that this is a development time concern, too, and has nothing to do with a production environment.
The security conscious Apple Inc. doesn't seem to think it's a big problem either, because Xcode sets it during development (see below).
I'm curious in what realistic scenario you think this is a real problem.
>
>> In a terminal session, simply:
>>
>> $ export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/path/to/Qt/Frameworks
>> $ open /apps/MyApp.app
>>
>> In Creator, just click run and this will be handled automatically. In qbs just type `qbs run -p foo` and this will be handled automatically.
>
> This won't work for apps launched directly via Finder/Dock.
Like I said, that doesn't matter. It didn't work in Qt 4 and the fact that it works in Qt 5 is a mere side effect. No one will notice.
Most people build Qt apps on OS X using some IDE, most likely Qt Creator. Are you seriously telling me you click build, go find the build directory, and launch the app in Finder? That's ridiculous. You click the run button. If you're willing to go through all the former effort you can easily export DYLD_LIBRARY_PATH at the beginning of your terminal session and type `open MyApp.app`. Note that the open command uses launch services which is the same as double clicking the bundle in Finder.
Furthermore, if you simply copy frameworks into the bundle at build time like every other native OS X app on the planet, this becomes a non-issue and you don't even need DYLD_LIBRARY_PATH. With my QMAKE_EMBEDDED_FRAMEWORKS suggestion, too, there would be a choice between the two, and be closer to native tools behaviour at the same time.
>> ANY solution that involves placing absolute paths in ANY file inside the MyApp.app/ directory tree is a wrong solution.
>
> You are wrong there. All system libs are referenced with their absolute paths.
Those are system libraries that are part of the operating system, present on every OS X installation in the world and not designed to be relocatable. Qt is not a system library and should be relocatable. Anything residing in /System has no bearing on this discussion.
> Moreover the Qt's lib/ absolute path will be there only during development, in deployed binary absolute path will be removed via install_name_tool -delete_rpath.
This still breaks the rule of absolute paths appearing somewhere. We do not want absolute paths anywhere during development except in per-session environment variables.
>> Note that Qt Creator already does the logical equivalent of what I described on Windows; the Qt libraries path is added to the PATH when the process is launched. Launching directly in Explorer doesn't work, and launching directly from Finder doesn't need to work either.
>
> Currently it DOES WORK when launching via Finder, because it does hardcode absolute path, so I don't see any reason it should stop working. Also it does work like that on Linux too.
Linux is not OS X (also did you forget about $ORIGIN?). And if we're going to compare to other operating systems, currently it DOESN'T work on Windows. Never seen a complaint about it. And that is not a problem because in 2014 people use IDEs and click the run button which configures search paths for you. This is why we have tools.
>> This is closer to how the native tools do things anyways.
>
> Which tools? AFAIK Xcode doesn't copy external frameworks into app bundle by default.
Yes it does. It has much specific functionality and behaviours for doing this and this technique is encouraged by Apple and used by pretty much every Xcode-using project on the planet. And the copying happens at development time, for both debug and release. No one postpones this process to a release-time packaging step like macdeployqt.
Examples of how Xcode facilitates this:
(1) Embedded binaries chooser on the Info tab of a target configuration
(2) Copy phase with an explicit selection for Frameworks on the Build Phases tab of a target configuration
(3) Default prompt to embed a framework in an application target when creating a new framework
(4) DYLIB_INSTALL_NAME_BASE set to @rpath by default when creating a new framework
(5) OS X: LD_RUNPATH_SEARCH_PATHS set to @executable_path/../Frameworks for apps and [@executable_path/../Frameworks, @loader_path/Frameworks] for frameworks when creating a new target
(6) iOS: LD_RUNPATH_SEARCH_PATHS set to @executable_path/Frameworks for apps and [@executable_path/Frameworks, @loader_path/Frameworks] for frameworks when creating a new target
(7) https://developer.apple.com/library/mac/documentation/macosx/conceptual/BPFrameworks/Tasks/CreatingFrameworks.html (some parts are outdated as DYLD_LIBRARY_PATH is now set automatically, but the rest of the documentation pretty much instructs users to do exactly what I am suggesting)
This is not a novel idea I just came up with. This has been the standard workflow on OS X for over a decade.
>> Symlinks make no sense. Just copy the full frameworks, there is no disadvantage to this. This is the standard workflow for development on Apple platforms anyways and has been since NeXTSTEP.
>
> See above.
>
>> I'm sure someone will bring up "performance!!1" but that is a poor argument;
>
> This is going off-topic. It was about to bring @rpath to Qt frameworks not rework entire workflow.
The whole point of @rpath is to enable this improvement in workflow. By itself there is no point in adding it other than *slightly* simplifying some macdeployqt code.
>>> I don't think you should add these by default since Qt doesn't need them, so unlikely your app need them. If you use some 2rd party library you are free to extend QMAKE_RPATH list yourself.
>>
>> It might need them. Depends if we change macdeployqt to place a dylibs (non-frameworks) build of Qt libraries inside Libraries instead of Frameworks. Not a major part of the discussion anyways, just an idea.
>
> I don't see point of handling some custom scenarios that anyway are not what is expected (standard) app bundle.
Fair enough, let's focus on the task at hand.
>> Let's use standard solutions instead of strange contraptions. Standard solutions involve @rpath along with DYLD_LIBRARY_PATH, copying frameworks at build time, or both (preferably both).
>
> I am sorry, but you are wrong. DYLD_LIBRARY_PATH is nowhere used in Xcode and DYLD_ variables exist for dyld debug purposes.
Apologies for parroting, but... you are in fact wrong. I've JUST tested this and Xcode does in fact set many environment variables when running an application. I've added NSLog(@"%@", [[NSProcessInfo processInfo] environment]); in my application delegate. Here's a subset of the output:
2014-08-02 17:12:48.775 Silverlock[24258:303] {
"DYLD_FRAMEWORK_PATH" = "/Users/jakepetroules/Library/Developer/Xcode/DerivedData/Silverlock-dozbffgewlkgfucjgrjfbjopeyhq/Build/Products/DebugAppStore";
"DYLD_LIBRARY_PATH" = "/Users/jakepetroules/Library/Developer/Xcode/DerivedData/Silverlock-dozbffgewlkgfucjgrjfbjopeyhq/Build/Products/DebugAppStore";
PATH = "/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin";
PWD = "/Users/jakepetroules/Library/Developer/Xcode/DerivedData/Silverlock-dozbffgewlkgfucjgrjfbjopeyhq/Build/Products/DebugAppStore";
"__XCODE_BUILT_PRODUCTS_DIR_PATHS" = "/Users/jakepetroules/Library/Developer/Xcode/DerivedData/Silverlock-dozbffgewlkgfucjgrjfbjopeyhq/Build/Products/DebugAppStore";
"__XPC_DYLD_FRAMEWORK_PATH" = "/Users/jakepetroules/Library/Developer/Xcode/DerivedData/Silverlock-dozbffgewlkgfucjgrjfbjopeyhq/Build/Products/DebugAppStore";
"__XPC_DYLD_LIBRARY_PATH" = "/Users/jakepetroules/Library/Developer/Xcode/DerivedData/Silverlock-dozbffgewlkgfucjgrjfbjopeyhq/Build/Products/DebugAppStore";
}
I work with Xcode on a daily basis building native Cocoa apps. I can assure you I'm well aware of the standards and conventions in use by Apple and their development tools. Bringing Qt in line with standard expectations for OS X and iOS development is important to maintain and grow its competitive edge. Tools like macdeployqt are an extremely foreign concept on OS X and iOS and are confusing to newcomers and annoying for veterans. No other SDK that I know if has anything of the sort, nor uses absolute sonames.
No need to mention MacPorts, Homebrew, etc., either, which probably use absolute paths for most builds. Package management systems in general have a whole set of conventions. For example, Fedora prohibits rpath usage in the package management system. This is correct and justified. Installed packages in a PMS are never relocated. Application bundles and SDKs on OS X *are*.
> Try to create simple framework and see what happens, checkout install name of built framework.
>
> $ otool -L /Users/ono/Library/Developer/Xcode/DerivedData/TestFramework-aduwyulqilsereeqgoizoxubgbdy/Build/Products/Debug/TestFramework.framework/TestFramework
> /Users/ono/Library/Developer/Xcode/DerivedData/TestFramework-aduwyulqilsereeqgoizoxubgbdy/Build/Products/Debug/TestFramework.framework/TestFramework:
> /Library/Frameworks/TestFramework.framework/Versions/A/TestFramework (compatibility version 1.0.0, current version 1.0.0)
> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 20.0.0)
> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1056.13.0)
> /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
>
>
>
> Now create a Cocoa app and framework from the framework project as see how the framework is referred and check if you can find the framework inside bundle.
>
> $ otool -L /Users/ono/Library/Developer/Xcode/DerivedData/SampleApp-fwmalbohyjlyqgdhjvnicwjqqmfr/Build/Products/Debug/SampleApp.app/Contents/MacOS/SampleApp
> /Users/ono/Library/Developer/Xcode/DerivedData/SampleApp-fwmalbohyjlyqgdhjvnicwjqqmfr/Build/Products/Debug/SampleApp.app/Contents/MacOS/SampleApp:
> /Library/Frameworks/TestFramework.framework/Versions/A/TestFramework (compatibility version 1.0.0, current version 1.0.0)
> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 20.0.0)
> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1056.13.0)
> /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1265.19.0)
Point being? The system default DYLIB_INSTALL_NAME_BASE for frameworks in the Xcode build system happens to be /Library/Frameworks. For new projects it should be set to @rpath (and the IDE does this when creating a new target). Nothing to see here.
> --
> Adam
So, let's certainly start with adding @rpath to Qt libraries. But let's not stop there, either.
--
Jake Petroules - jake.petroules at petroules.com
Chief Technology Officer - Petroules Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jake.petroules at petroules.com Sun Aug 3 01:39:00 2014
From: jake.petroules at petroules.com (Jake Petroules)
Date: Sat, 2 Aug 2014 18:39:00 -0400
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To:
References: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
<53DBF1F5.7030401@tungware.se>
<4BF629EA-C68A-434B-A042-27EA671D92FF@petroules.com>
Message-ID: <4A3F9CEC-5459-4F42-9426-875D0D8B7E69@petroules.com>
On 2014-08-02, at 05:04 AM, Adam Strzelecki wrote:
>> Please don't exaggerate the performance implications of copying a few frameworks on the first build (…)
>
> This can be done, but discussion is going off-topic.
>
> Let us try first to move Qt frameworks to use @rpath & remove some unnecessary operations while keeping current workflow with minimal changes to the code. Therefore I hereby propose to (1) keep rpath to Qt SDK in built app executable, (2) not copy anything on build, (3) make macdeploy modify ONLY executable removing absolute rpath (instead fixing frameworks), and (4) just copy needed frameworks and (5) optionally sign whole bundle.
>
> This will not require any wrappers, environment variables or changes in Qt Creator to run your app. Only Qmake and macdeploy need to be changed.
>
> Frankly I don't see anything wrong with keeping full path to SDK in executable when it isn't yet completely bundled. And the initial intention was to NOT touch Qt SDK modules once they are built.
>
> Once this is done & working we can follow this discussion and think what can be done next.
>
> --
> Adam
This isn't off topic at all. @rpath, copying frameworks, DYLD_ environment variables are all inseparably linked and very much part of the same discussion and overall issue. Your proposal to simply add @rpath and do nothing else has no benefits. What problem does it solve, other than deleting a bit of code from macdeployqt that currently works and will continue to work without maintenance? None. There is no point in doing it unless we go all the way and make the Qt SDK completely relocatable.
I understand you want to start by completing one objective at a time, but keep in mind each of these objectives is part of a greater overall goal. Alone, they are pointless.
>> Actually you CAN add Info.plist to bundle-less apps using the linker arguments: `-sectcreate __TEXT __info_plist Info.plist` which will embed it in the binary. All OS X APIs handle this transparently. Though, LSEnvironment is not a good solution for the problem we are trying to solve here.
>
> I was expecting that ;) But wasn't your intention to not modify binary once it has been built and not hardcode any paths into it?
Yes, which is why I said LSEnvironment is not a good solution.
>> Why would you do any of these things?
>
> Because you dislike adding absolute rpath to Qt SDK in built binary during dev process.
All of those things involve hardcoding absolute paths *somewhere*. There should be no absolute paths *anywhere* except environment variables that are automatically set per-session.
>> "Inject"? DYLD_LIBRARY_PATH is an environment variable. You simply set it in the process's environment before spawning.
>
> It is not so simple, first of all as you shown it works only from console, but if you launch it via GUI you need this variable to be set in launchd. As ~/.launchd.conf doesn't work anymore since Lion only permanent solution is to use /etc/launchd-user.conf which require admin to create/modify.
>
> Secondly DYLD_LIBRARY_PATH has strong security implications as the path is searched BEFORE default locations. So it does in fact let you inject/replace libraries. This is the reason dyld disables that for any process running under root account.
>
> man dyld
>
> DYLD_LIBRARY_PATH
>
> The dynamic linker searches these directories BEFORE it searches the default locations for libraries.
>
> What might be considered there is DYLD_FALLBACK_FRAMEWORK_PATH.
This is another excuse - there are no real security implications in practice. If you're even thinking about this, your machine has already been compromised and you no longer own it. Remember that this is a development time concern, too, and has nothing to do with a production environment.
The security conscious Apple Inc. doesn't seem to think it's a big problem either, because Xcode sets it during development (see below).
I'm curious in what realistic scenario you think this is a real problem.
>
>> In a terminal session, simply:
>>
>> $ export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/path/to/Qt/Frameworks
>> $ open /apps/MyApp.app
>>
>> In Creator, just click run and this will be handled automatically. In qbs just type `qbs run -p foo` and this will be handled automatically.
>
> This won't work for apps launched directly via Finder/Dock.
Like I said, that doesn't matter. It didn't work in Qt 4 and the fact that it works in Qt 5 is a mere side effect. No one will notice.
Most people build Qt apps on OS X using some IDE, most likely Qt Creator. Are you seriously telling me you click build, go find the build directory, and launch the app in Finder? That's ridiculous. You click the run button. If you're willing to go through all the former effort you can easily export DYLD_LIBRARY_PATH at the beginning of your terminal session and type `open MyApp.app`. Note that the open command uses launch services which is the same as double clicking the bundle in Finder.
Furthermore, if you simply copy frameworks into the bundle at build time like every other native OS X app on the planet, this becomes a non-issue and you don't even need DYLD_LIBRARY_PATH. With my QMAKE_EMBEDDED_FRAMEWORKS suggestion, too, there would be a choice between the two, and be closer to native tools behaviour at the same time.
>> ANY solution that involves placing absolute paths in ANY file inside the MyApp.app/ directory tree is a wrong solution.
>
> You are wrong there. All system libs are referenced with their absolute paths.
Those are system libraries that are part of the operating system, present on every OS X installation in the world and not designed to be relocatable. Qt is not a system library and should be relocatable. Anything residing in /System has no bearing on this discussion.
> Moreover the Qt's lib/ absolute path will be there only during development, in deployed binary absolute path will be removed via install_name_tool -delete_rpath.
This still breaks the rule of absolute paths appearing somewhere. We do not want absolute paths anywhere during development except in per-session environment variables.
>> Note that Qt Creator already does the logical equivalent of what I described on Windows; the Qt libraries path is added to the PATH when the process is launched. Launching directly in Explorer doesn't work, and launching directly from Finder doesn't need to work either.
>
> Currently it DOES WORK when launching via Finder, because it does hardcode absolute path, so I don't see any reason it should stop working. Also it does work like that on Linux too.
Linux is not OS X (also did you forget about $ORIGIN?). And if we're going to compare to other operating systems, currently it DOESN'T work on Windows. Never seen a complaint about it. And that is not a problem because in 2014 people use IDEs and click the run button which configures search paths for you. This is why we have tools.
>> This is closer to how the native tools do things anyways.
>
> Which tools? AFAIK Xcode doesn't copy external frameworks into app bundle by default.
Yes it does. It has much specific functionality and behaviours for doing this and this technique is encouraged by Apple and used by pretty much every Xcode-using project on the planet. And the copying happens at development time, for both debug and release. No one postpones this process to a release-time packaging step like macdeployqt.
Examples of how Xcode facilitates this:
(1) Embedded binaries chooser on the Info tab of a target configuration
(2) Copy phase with an explicit selection for Frameworks on the Build Phases tab of a target configuration
(3) Default prompt to embed a framework in an application target when creating a new framework
(4) DYLIB_INSTALL_NAME_BASE set to @rpath by default when creating a new framework
(5) OS X: LD_RUNPATH_SEARCH_PATHS set to @executable_path/../Frameworks for apps and [@executable_path/../Frameworks, @loader_path/Frameworks] for frameworks when creating a new target
(6) iOS: LD_RUNPATH_SEARCH_PATHS set to @executable_path/Frameworks for apps and [@executable_path/Frameworks, @loader_path/Frameworks] for frameworks when creating a new target
(7) https://developer.apple.com/library/mac/documentation/macosx/conceptual/BPFrameworks/Tasks/CreatingFrameworks.html (some parts are outdated as DYLD_LIBRARY_PATH is now set automatically, but the rest of the documentation pretty much instructs users to do exactly what I am suggesting)
This is not a novel idea I just came up with. This has been the standard workflow on OS X for over a decade.
>> Symlinks make no sense. Just copy the full frameworks, there is no disadvantage to this. This is the standard workflow for development on Apple platforms anyways and has been since NeXTSTEP.
>
> See above.
>
>> I'm sure someone will bring up "performance!!1" but that is a poor argument;
>
> This is going off-topic. It was about to bring @rpath to Qt frameworks not rework entire workflow.
The whole point of @rpath is to enable this improvement in workflow. By itself there is no point in adding it other than *slightly* simplifying some macdeployqt code.
>>> I don't think you should add these by default since Qt doesn't need them, so unlikely your app need them. If you use some 2rd party library you are free to extend QMAKE_RPATH list yourself.
>>
>> It might need them. Depends if we change macdeployqt to place a dylibs (non-frameworks) build of Qt libraries inside Libraries instead of Frameworks. Not a major part of the discussion anyways, just an idea.
>
> I don't see point of handling some custom scenarios that anyway are not what is expected (standard) app bundle.
Fair enough, let's focus on the task at hand.
>> Let's use standard solutions instead of strange contraptions. Standard solutions involve @rpath along with DYLD_LIBRARY_PATH, copying frameworks at build time, or both (preferably both).
>
> I am sorry, but you are wrong. DYLD_LIBRARY_PATH is nowhere used in Xcode and DYLD_ variables exist for dyld debug purposes.
Apologies for parroting, but... you are in fact wrong. I've JUST tested this and Xcode does in fact set many environment variables when running an application. I've added NSLog(@"%@", [[NSProcessInfo processInfo] environment]); in my application delegate. Here's a subset of the output:
2014-08-02 17:12:48.775 Silverlock[24258:303] {
"DYLD_FRAMEWORK_PATH" = "/Users/jakepetroules/Library/Developer/Xcode/DerivedData/Silverlock-dozbffgewlkgfucjgrjfbjopeyhq/Build/Products/DebugAppStore";
"DYLD_LIBRARY_PATH" = "/Users/jakepetroules/Library/Developer/Xcode/DerivedData/Silverlock-dozbffgewlkgfucjgrjfbjopeyhq/Build/Products/DebugAppStore";
PATH = "/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin";
PWD = "/Users/jakepetroules/Library/Developer/Xcode/DerivedData/Silverlock-dozbffgewlkgfucjgrjfbjopeyhq/Build/Products/DebugAppStore";
"__XCODE_BUILT_PRODUCTS_DIR_PATHS" = "/Users/jakepetroules/Library/Developer/Xcode/DerivedData/Silverlock-dozbffgewlkgfucjgrjfbjopeyhq/Build/Products/DebugAppStore";
"__XPC_DYLD_FRAMEWORK_PATH" = "/Users/jakepetroules/Library/Developer/Xcode/DerivedData/Silverlock-dozbffgewlkgfucjgrjfbjopeyhq/Build/Products/DebugAppStore";
"__XPC_DYLD_LIBRARY_PATH" = "/Users/jakepetroules/Library/Developer/Xcode/DerivedData/Silverlock-dozbffgewlkgfucjgrjfbjopeyhq/Build/Products/DebugAppStore";
}
I work with Xcode on a daily basis building native Cocoa apps. I can assure you I'm well aware of the standards and conventions in use by Apple and their development tools. Bringing Qt in line with standard expectations for OS X and iOS development is important to maintain and grow its competitive edge. Tools like macdeployqt are an extremely foreign concept on OS X and iOS and are confusing to newcomers and annoying for veterans. No other SDK that I know if has anything of the sort, nor uses absolute sonames.
No need to mention MacPorts, Homebrew, etc., either, which probably use absolute paths for most builds. Package management systems in general have a whole set of conventions. For example, Fedora prohibits rpath usage in the package management system. This is correct and justified. Installed packages in a PMS are never relocated. Application bundles and SDKs on OS X *are*.
> Try to create simple framework and see what happens, checkout install name of built framework.
>
> $ otool -L /Users/ono/Library/Developer/Xcode/DerivedData/TestFramework-aduwyulqilsereeqgoizoxubgbdy/Build/Products/Debug/TestFramework.framework/TestFramework
> /Users/ono/Library/Developer/Xcode/DerivedData/TestFramework-aduwyulqilsereeqgoizoxubgbdy/Build/Products/Debug/TestFramework.framework/TestFramework:
> /Library/Frameworks/TestFramework.framework/Versions/A/TestFramework (compatibility version 1.0.0, current version 1.0.0)
> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 20.0.0)
> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1056.13.0)
> /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
>
>
>
> Now create a Cocoa app and framework from the framework project as see how the framework is referred and check if you can find the framework inside bundle.
>
> $ otool -L /Users/ono/Library/Developer/Xcode/DerivedData/SampleApp-fwmalbohyjlyqgdhjvnicwjqqmfr/Build/Products/Debug/SampleApp.app/Contents/MacOS/SampleApp
> /Users/ono/Library/Developer/Xcode/DerivedData/SampleApp-fwmalbohyjlyqgdhjvnicwjqqmfr/Build/Products/Debug/SampleApp.app/Contents/MacOS/SampleApp:
> /Library/Frameworks/TestFramework.framework/Versions/A/TestFramework (compatibility version 1.0.0, current version 1.0.0)
> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 20.0.0)
> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1056.13.0)
> /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1265.19.0)
Point being? The system default DYLIB_INSTALL_NAME_BASE for frameworks in the Xcode build system happens to be /Library/Frameworks. For new projects it should be set to @rpath (and the IDE does this when creating a new target). Nothing to see here.
> --
> Adam
So, let's certainly start with adding @rpath to Qt libraries. But let's not stop there, either.
--
Jake Petroules - jake.petroules at petroules.com
Chief Technology Officer - Petroules Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From Martin.Smith at digia.com Sun Aug 3 10:42:10 2014
From: Martin.Smith at digia.com (Smith Martin)
Date: Sun, 3 Aug 2014 07:42:10 +0000
Subject: [Development] [docs/c++] How do we deal with the special
member functions (copy/move ctor/assignment operator, dtor,
default ctor)
In-Reply-To: <3783897.zvvUg1BiLp@tjmaciei-mobl4>
References: <201408012316.40275.marc.mutz@kdab.com>,
<3783897.zvvUg1BiLp@tjmaciei-mobl4>
Message-ID: <3596A8D0230F7A43BCA8542D0D65F8704BB607@IT-EXMB01-HKI.it.local>
qdoc decides which members must be documented by parsing the .h file looking for the members that are not private. Any such member that does not later have a qdoc comment is a "documentation missing" error. It has simply always been that way, but we can change it if that makes sense. It does recognize the constructors and destructor. The way to tell qdoc to ignore a member is to give it a qdoc comment that contains nothing but "\internal"
martin
________________________________________
From: development-bounces+martin.smith=digia.com at qt-project.org [development-bounces+martin.smith=digia.com at qt-project.org] on behalf of Thiago Macieira [thiago.macieira at intel.com]
Sent: Saturday, August 02, 2014 6:21 PM
To: development at qt-project.org
Subject: Re: [Development] [docs/c++] How do we deal with the special member functions (copy/move ctor/assignment operator, dtor, default ctor)
On Friday 01 August 2014 23:16:40 Marc Mutz wrote:
> That leaves the question how to deal with the documentation for these
> implicit members.
Why do we have to document them in the first place? I hate having to write
documentation for a destructor that simply says "frees resources associated
with this object". That much is obvious: any self-respecting destructor will
do that and the same applies to copy and move constructors.
What we really want is to document which objects are copyable and which ones
aren't. And that is very simple: any object with Q_DISABLE_COPY is not
copyable, (almost) everything else is.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
From Martin.Smith at digia.com Sun Aug 3 10:42:10 2014
From: Martin.Smith at digia.com (Smith Martin)
Date: Sun, 3 Aug 2014 07:42:10 +0000
Subject: [Development] [docs/c++] How do we deal with the special
member functions (copy/move ctor/assignment operator, dtor,
default ctor)
In-Reply-To: <3783897.zvvUg1BiLp@tjmaciei-mobl4>
References: <201408012316.40275.marc.mutz@kdab.com>,
<3783897.zvvUg1BiLp@tjmaciei-mobl4>
Message-ID: <3596A8D0230F7A43BCA8542D0D65F8704BB607@IT-EXMB01-HKI.it.local>
qdoc decides which members must be documented by parsing the .h file looking for the members that are not private. Any such member that does not later have a qdoc comment is a "documentation missing" error. It has simply always been that way, but we can change it if that makes sense. It does recognize the constructors and destructor. The way to tell qdoc to ignore a member is to give it a qdoc comment that contains nothing but "\internal"
martin
________________________________________
From: development-bounces+martin.smith=digia.com at qt-project.org [development-bounces+martin.smith=digia.com at qt-project.org] on behalf of Thiago Macieira [thiago.macieira at intel.com]
Sent: Saturday, August 02, 2014 6:21 PM
To: development at qt-project.org
Subject: Re: [Development] [docs/c++] How do we deal with the special member functions (copy/move ctor/assignment operator, dtor, default ctor)
On Friday 01 August 2014 23:16:40 Marc Mutz wrote:
> That leaves the question how to deal with the documentation for these
> implicit members.
Why do we have to document them in the first place? I hate having to write
documentation for a destructor that simply says "frees resources associated
with this object". That much is obvious: any self-respecting destructor will
do that and the same applies to copy and move constructors.
What we really want is to document which objects are copyable and which ones
aren't. And that is very simple: any object with Q_DISABLE_COPY is not
copyable, (almost) everything else is.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
From ono at java.pl Sun Aug 3 13:11:17 2014
From: ono at java.pl (Adam Strzelecki)
Date: Sun, 3 Aug 2014 12:11:17 +0200
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To: <4A3F9CEC-5459-4F42-9426-875D0D8B7E69@petroules.com>
References: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
<53DBF1F5.7030401@tungware.se>
<4BF629EA-C68A-434B-A042-27EA671D92FF@petroules.com>
<4A3F9CEC-5459-4F42-9426-875D0D8B7E69@petroules.com>
Message-ID: <739BD054-A176-4991-8928-CED4493BF0F4@java.pl>
> Your proposal to simply add @rpath and do nothing else has no benefits. What problem does it solve, other than deleting a bit of code from macdeployqt that currently works and will continue to work without maintenance? None.
My original intention was to stop rewriting headers of Qt modules on install and app deploy.
I am aware it opens new possibilities, like these you proposed, including making macdeployqt as part of Qmake build step optional or default (upon request).
I wish also we had pure drag&drop Mac way installation of Qt SDK instead of this fancy installer that does just copying.
> There is no point in doing it unless we go all the way and make the Qt SDK completely relocatable.
Agreed.
> I understand you want to start by completing one objective at a time, but keep in mind each of these objectives is part of a greater overall goal. Alone, they are pointless.
Agreed.
> Furthermore, if you simply copy frameworks into the bundle at build time like every other native OS X app on the planet, this becomes a non-issue and you don't even need DYLD_LIBRARY_PATH. With my QMAKE_EMBEDDED_FRAMEWORKS suggestion, too, there would be a choice between the two, and be closer to native tools behaviour at the same time.
It isn't about copying few KB or few MB, Qt frameworks weight much more. Are you telling me that each Qt SDK example should have its own copy of Qt frameworks BY DEFAULT which makes around ~100 copies of Qt frameworks !?
> Those are system libraries that are part of the operating system, present on every OS X installation in the world and not designed to be relocatable. Qt is not a system library and should be relocatable. Anything residing in /System has no bearing on this discussion.
I gave you an example with external framework whose install name is set BY DEFAULT by Xcode to /Library/Frameworks/FrameworkName.framework and it isn't /System.
> This still breaks the rule of absolute paths appearing somewhere. We do not want absolute paths anywhere during development except in per-session environment variables.
I gave you a clean example that Xcode (still!?) defaults to /Library/Frameworks for new projects/targets.
> Linux is not OS X (also did you forget about $ORIGIN?).
You are talking about Linux kernel vs XNU or GNU/Linux which was inspired by BSD and OSX which is again based on BSD. So we are much closer to Linux that Windows. This is especially visible in Qmake scripts and code that is mostly common on Linux & Mac.
It is very likely also that someone will pin newly create app to the dock, and once it is pinned it won't work. I do really see benefit to keep absolute rpath to Qt SDK during dev process, until deploy.
>> Which tools? AFAIK Xcode doesn't copy external frameworks into app bundle by default.
>
> Yes it does.
Maybe I was not clear enough, but again not it doesn't BY DEFAULT, Xcode does not copy any frameworks BY DEFAULT into app bundle. Again I am talking about default behavior not behavior requested & not Xcode capabilities.
> Examples of how Xcode facilitates this:
This example exhibits explicit setting in Xcode project to copy selected frameworks into the bundle. But please remember you want this behavior to be default for Qmake (qbs?) Qt based app build. All I am saying this shouldn't be default.
> This is not a novel idea I just came up with. This has been the standard workflow on OS X for over a decade.
I am not arguing with that. I am just arguing with proposed default behavior.
I am perfectly okay with ability to copy frameworks on build if it is requested by developer via CONFIG += bundle_on_build or whatever. But I am against doing it by default. I am running SSD on my both iMac & MBP since a while, but not anyone does.
Please note that there is also some reasoning behind Copy Files Xcode build step option "Copy only when installing".
> The whole point of @rpath is to enable this improvement in workflow. By itself there is no point in adding it other than *slightly* simplifying some macdeployqt code.
Again, I am not against having a switch to do what you tell during build time. But for other users sake I don't want to make it default.
> Apologies for parroting, but... you are in fact wrong. I've JUST tested this and Xcode does in fact set many environment variables when running an application. I've added NSLog(@"%@", [[NSProcessInfo processInfo] environment]);
Apologies taken. Especially having that I was wrong. Indeed Xcode does that for sake of frameworks being part of project that are yet not installed. Yet DYLD_FRAMEWORK_PATH serves bit different purpose here, it makes the app work even there is no framework yet in /Library/Frameworks.
> I work with Xcode on a daily basis building native Cocoa apps. (…)
I am sorry, it wasn't my intention to negate your skills or whatsoever. I am really happy that you take part of this discussion.
> Point being? The system default DYLIB_INSTALL_NAME_BASE for frameworks in the Xcode build system happens to be /Library/Frameworks. For new projects it should be set to @rpath (and the IDE does this when creating a new target). Nothing to see here.
Can you please check this, because I checked it twice and neither creating new Cocoa framework project nor adding new Cocoa framework target resulted in having @rpath as install name.
So altogether I think best solution is to symlink all needed frameworks on build. This removes need to make proper change in Qt Creator to use DYLD_FRAMEWORK_PATH, makes app work via Dock/Finder even it is not yet completely bundled.
Such symlink may be relative (if possible) so all Qt examples may be built but not "bundled", therefore their will use single copies of frameworks.
I am perfectly okay to have "bundle_on_build" config which makes "make" behave as "make" & "make deploy" so it will satisfy your needs.
WDYT?
Regards,
--
Adam
From ono at java.pl Sun Aug 3 13:11:17 2014
From: ono at java.pl (Adam Strzelecki)
Date: Sun, 3 Aug 2014 12:11:17 +0200
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To: <4A3F9CEC-5459-4F42-9426-875D0D8B7E69@petroules.com>
References: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
<53DBF1F5.7030401@tungware.se>
<4BF629EA-C68A-434B-A042-27EA671D92FF@petroules.com>
<4A3F9CEC-5459-4F42-9426-875D0D8B7E69@petroules.com>
Message-ID: <739BD054-A176-4991-8928-CED4493BF0F4@java.pl>
> Your proposal to simply add @rpath and do nothing else has no benefits. What problem does it solve, other than deleting a bit of code from macdeployqt that currently works and will continue to work without maintenance? None.
My original intention was to stop rewriting headers of Qt modules on install and app deploy.
I am aware it opens new possibilities, like these you proposed, including making macdeployqt as part of Qmake build step optional or default (upon request).
I wish also we had pure drag&drop Mac way installation of Qt SDK instead of this fancy installer that does just copying.
> There is no point in doing it unless we go all the way and make the Qt SDK completely relocatable.
Agreed.
> I understand you want to start by completing one objective at a time, but keep in mind each of these objectives is part of a greater overall goal. Alone, they are pointless.
Agreed.
> Furthermore, if you simply copy frameworks into the bundle at build time like every other native OS X app on the planet, this becomes a non-issue and you don't even need DYLD_LIBRARY_PATH. With my QMAKE_EMBEDDED_FRAMEWORKS suggestion, too, there would be a choice between the two, and be closer to native tools behaviour at the same time.
It isn't about copying few KB or few MB, Qt frameworks weight much more. Are you telling me that each Qt SDK example should have its own copy of Qt frameworks BY DEFAULT which makes around ~100 copies of Qt frameworks !?
> Those are system libraries that are part of the operating system, present on every OS X installation in the world and not designed to be relocatable. Qt is not a system library and should be relocatable. Anything residing in /System has no bearing on this discussion.
I gave you an example with external framework whose install name is set BY DEFAULT by Xcode to /Library/Frameworks/FrameworkName.framework and it isn't /System.
> This still breaks the rule of absolute paths appearing somewhere. We do not want absolute paths anywhere during development except in per-session environment variables.
I gave you a clean example that Xcode (still!?) defaults to /Library/Frameworks for new projects/targets.
> Linux is not OS X (also did you forget about $ORIGIN?).
You are talking about Linux kernel vs XNU or GNU/Linux which was inspired by BSD and OSX which is again based on BSD. So we are much closer to Linux that Windows. This is especially visible in Qmake scripts and code that is mostly common on Linux & Mac.
It is very likely also that someone will pin newly create app to the dock, and once it is pinned it won't work. I do really see benefit to keep absolute rpath to Qt SDK during dev process, until deploy.
>> Which tools? AFAIK Xcode doesn't copy external frameworks into app bundle by default.
>
> Yes it does.
Maybe I was not clear enough, but again not it doesn't BY DEFAULT, Xcode does not copy any frameworks BY DEFAULT into app bundle. Again I am talking about default behavior not behavior requested & not Xcode capabilities.
> Examples of how Xcode facilitates this:
This example exhibits explicit setting in Xcode project to copy selected frameworks into the bundle. But please remember you want this behavior to be default for Qmake (qbs?) Qt based app build. All I am saying this shouldn't be default.
> This is not a novel idea I just came up with. This has been the standard workflow on OS X for over a decade.
I am not arguing with that. I am just arguing with proposed default behavior.
I am perfectly okay with ability to copy frameworks on build if it is requested by developer via CONFIG += bundle_on_build or whatever. But I am against doing it by default. I am running SSD on my both iMac & MBP since a while, but not anyone does.
Please note that there is also some reasoning behind Copy Files Xcode build step option "Copy only when installing".
> The whole point of @rpath is to enable this improvement in workflow. By itself there is no point in adding it other than *slightly* simplifying some macdeployqt code.
Again, I am not against having a switch to do what you tell during build time. But for other users sake I don't want to make it default.
> Apologies for parroting, but... you are in fact wrong. I've JUST tested this and Xcode does in fact set many environment variables when running an application. I've added NSLog(@"%@", [[NSProcessInfo processInfo] environment]);
Apologies taken. Especially having that I was wrong. Indeed Xcode does that for sake of frameworks being part of project that are yet not installed. Yet DYLD_FRAMEWORK_PATH serves bit different purpose here, it makes the app work even there is no framework yet in /Library/Frameworks.
> I work with Xcode on a daily basis building native Cocoa apps. (…)
I am sorry, it wasn't my intention to negate your skills or whatsoever. I am really happy that you take part of this discussion.
> Point being? The system default DYLIB_INSTALL_NAME_BASE for frameworks in the Xcode build system happens to be /Library/Frameworks. For new projects it should be set to @rpath (and the IDE does this when creating a new target). Nothing to see here.
Can you please check this, because I checked it twice and neither creating new Cocoa framework project nor adding new Cocoa framework target resulted in having @rpath as install name.
So altogether I think best solution is to symlink all needed frameworks on build. This removes need to make proper change in Qt Creator to use DYLD_FRAMEWORK_PATH, makes app work via Dock/Finder even it is not yet completely bundled.
Such symlink may be relative (if possible) so all Qt examples may be built but not "bundled", therefore their will use single copies of frameworks.
I am perfectly okay to have "bundle_on_build" config which makes "make" behave as "make" & "make deploy" so it will satisfy your needs.
WDYT?
Regards,
--
Adam
From milian.wolff at kdab.com Sun Aug 3 17:27:02 2014
From: milian.wolff at kdab.com (Milian Wolff)
Date: Sun, 03 Aug 2014 16:27:02 +0200
Subject: [Development] QZipReader and QZipWriter
In-Reply-To: <213CA41A-1DF5-44AE-B93F-3FBB19943F39@gmx.de>
References:
<21985962.1jl2FyDo8B@tjmaciei-mobl4>
<213CA41A-1DF5-44AE-B93F-3FBB19943F39@gmx.de>
Message-ID: <6864665.3t85P1d1Gc@minime>
On Sunday 03 August 2014 00:08:28 Gunnar Roth wrote:
> > Am 02.08.2014 um 18:14 schrieb Thiago Macieira
> > :
> >
> >
> > And to be honest, while convenient, this is not a must-have feature. With
> > my OSS hat on, I would say (L)GPL-averse customers could be served right
> > by their aversion by having one fewer solution.
>
> As someone who has a qt commercial license for some years now and advocated
> the use of qt commercial internally, so we have bought nearly about some
> dozen licenses, this is interesting to hear , what kind of appreciation we
> get for paying thousands of euros each year. Nice…no so.
Please keep in mind that a) Thiago expressed his personal opinion, clearly
marked with the "OSS hat on", and b) there is nothing preventing you from
using a KDE framework in a commercial environment, as all frameworks are LGPL
licensed.
Bye
--
Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4773 bytes
Desc: not available
URL:
From milian.wolff at kdab.com Sun Aug 3 17:27:02 2014
From: milian.wolff at kdab.com (Milian Wolff)
Date: Sun, 03 Aug 2014 16:27:02 +0200
Subject: [Development] QZipReader and QZipWriter
In-Reply-To: <213CA41A-1DF5-44AE-B93F-3FBB19943F39@gmx.de>
References:
<21985962.1jl2FyDo8B@tjmaciei-mobl4>
<213CA41A-1DF5-44AE-B93F-3FBB19943F39@gmx.de>
Message-ID: <6864665.3t85P1d1Gc@minime>
On Sunday 03 August 2014 00:08:28 Gunnar Roth wrote:
> > Am 02.08.2014 um 18:14 schrieb Thiago Macieira
> > :
> >
> >
> > And to be honest, while convenient, this is not a must-have feature. With
> > my OSS hat on, I would say (L)GPL-averse customers could be served right
> > by their aversion by having one fewer solution.
>
> As someone who has a qt commercial license for some years now and advocated
> the use of qt commercial internally, so we have bought nearly about some
> dozen licenses, this is interesting to hear , what kind of appreciation we
> get for paying thousands of euros each year. Nice…no so.
Please keep in mind that a) Thiago expressed his personal opinion, clearly
marked with the "OSS hat on", and b) there is nothing preventing you from
using a KDE framework in a commercial environment, as all frameworks are LGPL
licensed.
Bye
--
Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4773 bytes
Desc: not available
URL:
From jake.petroules at petroules.com Mon Aug 4 00:24:11 2014
From: jake.petroules at petroules.com (Jake Petroules)
Date: Sun, 3 Aug 2014 17:24:11 -0400
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To: <739BD054-A176-4991-8928-CED4493BF0F4@java.pl>
References: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
<53DBF1F5.7030401@tungware.se>
<4BF629EA-C68A-434B-A042-27EA671D92FF@petroules.com>
<4A3F9CEC-5459-4F42-9426-875D0D8B7E69@petroules.com>
<739BD054-A176-4991-8928-CED4493BF0F4@java.pl>
Message-ID:
On 2014-08-03, at 06:11 AM, Adam Strzelecki wrote:
>> Your proposal to simply add @rpath and do nothing else has no benefits. What problem does it solve, other than deleting a bit of code from macdeployqt that currently works and will continue to work without maintenance? None.
>
> My original intention was to stop rewriting headers of Qt modules on install and app deploy.
>
> I am aware it opens new possibilities, like these you proposed, including making macdeployqt as part of Qmake build step optional or default (upon request).
>
> I wish also we had pure drag&drop Mac way installation of Qt SDK instead of this fancy installer that does just copying.
Yes, that's the idea. The installer would probably remain anyways, but we'll see.
>> There is no point in doing it unless we go all the way and make the Qt SDK completely relocatable.
>
> Agreed.
>
>> I understand you want to start by completing one objective at a time, but keep in mind each of these objectives is part of a greater overall goal. Alone, they are pointless.
>
> Agreed.
>
>> Furthermore, if you simply copy frameworks into the bundle at build time like every other native OS X app on the planet, this becomes a non-issue and you don't even need DYLD_LIBRARY_PATH. With my QMAKE_EMBEDDED_FRAMEWORKS suggestion, too, there would be a choice between the two, and be closer to native tools behaviour at the same time.
>
> It isn't about copying few KB or few MB, Qt frameworks weight much more. Are you telling me that each Qt SDK example should have its own copy of Qt frameworks BY DEFAULT which makes around ~100 copies of Qt frameworks !?
Demos within the SDK can just have an extra runpath search path added... like @executable_path/../../../../../../lib or something, no need to copy the frameworks for that. For user apps it's a whole different story.
>> Those are system libraries that are part of the operating system, present on every OS X installation in the world and not designed to be relocatable. Qt is not a system library and should be relocatable. Anything residing in /System has no bearing on this discussion.
>
> I gave you an example with external framework whose install name is set BY DEFAULT by Xcode to /Library/Frameworks/FrameworkName.framework and it isn't /System.
I think you're a little confused about the meaning of default. There is a system level default in Xcode's configuration files (you can find this deep in the app bundle), which is /Library/Frameworks for frameworks. However, when creating a new framework target in Xcode 6, the user-level DYLIB_INSTALL_NAME_BASE is set to @rpath, which overrides the system-level /Library/Frameworks value. The system one cannot be changed for compatibility reasons.
>> This still breaks the rule of absolute paths appearing somewhere. We do not want absolute paths anywhere during development except in per-session environment variables.
>
> I gave you a clean example that Xcode (still!?) defaults to /Library/Frameworks for new projects/targets.
See above.
>> Linux is not OS X (also did you forget about $ORIGIN?).
>
> You are talking about Linux kernel vs XNU or GNU/Linux which was inspired by BSD and OSX which is again based on BSD. So we are much closer to Linux that Windows. This is especially visible in Qmake scripts and code that is mostly common on Linux & Mac.
>
> It is very likely also that someone will pin newly create app to the dock, and once it is pinned it won't work. I do really see benefit to keep absolute rpath to Qt SDK during dev process, until deploy.
I still don't consider this an issue. If you really want it that badly, add the following (or something of the sort, I don't know qmake) in YOUR app target in qmake:
QMAKE_LFLAGS_DEBUG += -Wl,-rpath,$$QT_INSTALL_LIBS
>>> Which tools? AFAIK Xcode doesn't copy external frameworks into app bundle by default.
>>
>> Yes it does.
>
> Maybe I was not clear enough, but again not it doesn't BY DEFAULT, Xcode does not copy any frameworks BY DEFAULT into app bundle. Again I am talking about default behavior not behavior requested & not Xcode capabilities.
In Xcode 6, when you create a new framework target, the first application target in the project is automatically selected for "embed in bundle" which you'd have to EXPLICITLY change for it to NOT be copied. Xcode 6 simply adds new and convenient UI for a practice that's been standard for over a decade. So yes, it does copy frameworks BY DEFAULT.
>> Examples of how Xcode facilitates this:
>
>
> This example exhibits explicit setting in Xcode project to copy selected frameworks into the bundle. But please remember you want this behavior to be default for Qmake (qbs?) Qt based app build. All I am saying this shouldn't be default.
We might be debating the meaning of "default". The default workflow should absolutely be to copy frameworks; I'm not saying that by default qmake should copy every framework into every app bundle without being told. Hence why QMAKE_EMBEDDED_FRAMEWORKS would be a user-set property. Much like qmake doesn't automatically invent values for SOURCES but you still need to set it to create anything useful.
There is a very simple solution to this problem. I and the majority of developers do this:
QMAKE_EMBEDDED_FRAMEWORKS = QtCore QtGui QtWidgets
You do this:
CONFIG(release, debug|release):QMAKE_EMBEDDED_FRAMEWORKS = QtCore QtGui QtWidgets
QMAKE_LFLAGS_DEBUG += -Wl,-rpath,$$QT_INSTALL_LIBS
>> This is not a novel idea I just came up with. This has been the standard workflow on OS X for over a decade.
>
> I am not arguing with that. I am just arguing with proposed default behavior.
>
> I am perfectly okay with ability to copy frameworks on build if it is requested by developer via CONFIG += bundle_on_build or whatever. But I am against doing it by default. I am running SSD on my both iMac & MBP since a while, but not anyone does.
I'm not running on an SSD and I have the slowest MacBook Pro imaginable (2008). I can assure you there is no performance degradation whatsoever when copying frameworks as part of the standard workflow. Also, like I said before... QMAKE_EMBEDDED_FRAMEWORKS. A CONFIG option is not necessary because if you don't want to copy things, simply don't set QMAKE_EMBEDDED_FRAMEWORKS, or set it for release configuration only.
> Please note that there is also some reasoning behind Copy Files Xcode build step option "Copy only when installing".
Which is unchecked by default and no one seems to use it. Either way I can assure you the reason for this setting was NOT a performance optimization for copying frameworks, in part because older versions of Xcode might not have actually set DYLD_LIBRARY_PATH/DYLD_FRAMEWORK_PATH.
>> The whole point of @rpath is to enable this improvement in workflow. By itself there is no point in adding it other than *slightly* simplifying some macdeployqt code.
>
> Again, I am not against having a switch to do what you tell during build time. But for other users sake I don't want to make it default.
For other users' sake we DO want to make it default. The workflows you want are foreign to every Mac developer out there.
>> Apologies for parroting, but... you are in fact wrong. I've JUST tested this and Xcode does in fact set many environment variables when running an application. I've added NSLog(@"%@", [[NSProcessInfo processInfo] environment]);
>
> Apologies taken. Especially having that I was wrong. Indeed Xcode does that for sake of frameworks being part of project that are yet not installed. Yet DYLD_FRAMEWORK_PATH serves bit different purpose here, it makes the app work even there is no framework yet in /Library/Frameworks.
>
>> I work with Xcode on a daily basis building native Cocoa apps. (…)
>
> I am sorry, it wasn't my intention to negate your skills or whatsoever. I am really happy that you take part of this discussion.
>
>> Point being? The system default DYLIB_INSTALL_NAME_BASE for frameworks in the Xcode build system happens to be /Library/Frameworks. For new projects it should be set to @rpath (and the IDE does this when creating a new target). Nothing to see here.
>
> Can you please check this, because I checked it twice and neither creating new Cocoa framework project nor adding new Cocoa framework target resulted in having @rpath as install name.
New in Xcode 6.
> So altogether I think best solution is to symlink all needed frameworks on build. This removes need to make proper change in Qt Creator to use DYLD_FRAMEWORK_PATH, makes app work via Dock/Finder even it is not yet completely bundled.
I'm curious why you think this will have a noticeable impact on performance. It is an unnecessary over-complication that actually leads to more bugs. Because this suggestion is contrary to every standard of Mac development, I will not accept this as a valid argument until you can provide benchmarks proving that there is a significant performance degradation.
Secondly, you're forgetting about user frameworks. Unless you copy those to the bundle at build time as well, currently, with Qt 5, your application WILL NOT work when launched via Dock/Finder. The fact that it works now for *some* apps is, like I mentioned before, a side effect.
> Such symlink may be relative (if possible) so all Qt examples may be built but not "bundled", therefore their will use single copies of frameworks.
>
> I am perfectly okay to have "bundle_on_build" config which makes "make" behave as "make" & "make deploy" so it will satisfy your needs.
>
> WDYT?
>
> Regards,
> --
> Adam
--
Jake Petroules - jake.petroules at petroules.com
Chief Technology Officer - Petroules Corporation
From jake.petroules at petroules.com Mon Aug 4 00:24:11 2014
From: jake.petroules at petroules.com (Jake Petroules)
Date: Sun, 3 Aug 2014 17:24:11 -0400
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To: <739BD054-A176-4991-8928-CED4493BF0F4@java.pl>
References: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
<53DBF1F5.7030401@tungware.se>
<4BF629EA-C68A-434B-A042-27EA671D92FF@petroules.com>
<4A3F9CEC-5459-4F42-9426-875D0D8B7E69@petroules.com>
<739BD054-A176-4991-8928-CED4493BF0F4@java.pl>
Message-ID:
On 2014-08-03, at 06:11 AM, Adam Strzelecki wrote:
>> Your proposal to simply add @rpath and do nothing else has no benefits. What problem does it solve, other than deleting a bit of code from macdeployqt that currently works and will continue to work without maintenance? None.
>
> My original intention was to stop rewriting headers of Qt modules on install and app deploy.
>
> I am aware it opens new possibilities, like these you proposed, including making macdeployqt as part of Qmake build step optional or default (upon request).
>
> I wish also we had pure drag&drop Mac way installation of Qt SDK instead of this fancy installer that does just copying.
Yes, that's the idea. The installer would probably remain anyways, but we'll see.
>> There is no point in doing it unless we go all the way and make the Qt SDK completely relocatable.
>
> Agreed.
>
>> I understand you want to start by completing one objective at a time, but keep in mind each of these objectives is part of a greater overall goal. Alone, they are pointless.
>
> Agreed.
>
>> Furthermore, if you simply copy frameworks into the bundle at build time like every other native OS X app on the planet, this becomes a non-issue and you don't even need DYLD_LIBRARY_PATH. With my QMAKE_EMBEDDED_FRAMEWORKS suggestion, too, there would be a choice between the two, and be closer to native tools behaviour at the same time.
>
> It isn't about copying few KB or few MB, Qt frameworks weight much more. Are you telling me that each Qt SDK example should have its own copy of Qt frameworks BY DEFAULT which makes around ~100 copies of Qt frameworks !?
Demos within the SDK can just have an extra runpath search path added... like @executable_path/../../../../../../lib or something, no need to copy the frameworks for that. For user apps it's a whole different story.
>> Those are system libraries that are part of the operating system, present on every OS X installation in the world and not designed to be relocatable. Qt is not a system library and should be relocatable. Anything residing in /System has no bearing on this discussion.
>
> I gave you an example with external framework whose install name is set BY DEFAULT by Xcode to /Library/Frameworks/FrameworkName.framework and it isn't /System.
I think you're a little confused about the meaning of default. There is a system level default in Xcode's configuration files (you can find this deep in the app bundle), which is /Library/Frameworks for frameworks. However, when creating a new framework target in Xcode 6, the user-level DYLIB_INSTALL_NAME_BASE is set to @rpath, which overrides the system-level /Library/Frameworks value. The system one cannot be changed for compatibility reasons.
>> This still breaks the rule of absolute paths appearing somewhere. We do not want absolute paths anywhere during development except in per-session environment variables.
>
> I gave you a clean example that Xcode (still!?) defaults to /Library/Frameworks for new projects/targets.
See above.
>> Linux is not OS X (also did you forget about $ORIGIN?).
>
> You are talking about Linux kernel vs XNU or GNU/Linux which was inspired by BSD and OSX which is again based on BSD. So we are much closer to Linux that Windows. This is especially visible in Qmake scripts and code that is mostly common on Linux & Mac.
>
> It is very likely also that someone will pin newly create app to the dock, and once it is pinned it won't work. I do really see benefit to keep absolute rpath to Qt SDK during dev process, until deploy.
I still don't consider this an issue. If you really want it that badly, add the following (or something of the sort, I don't know qmake) in YOUR app target in qmake:
QMAKE_LFLAGS_DEBUG += -Wl,-rpath,$$QT_INSTALL_LIBS
>>> Which tools? AFAIK Xcode doesn't copy external frameworks into app bundle by default.
>>
>> Yes it does.
>
> Maybe I was not clear enough, but again not it doesn't BY DEFAULT, Xcode does not copy any frameworks BY DEFAULT into app bundle. Again I am talking about default behavior not behavior requested & not Xcode capabilities.
In Xcode 6, when you create a new framework target, the first application target in the project is automatically selected for "embed in bundle" which you'd have to EXPLICITLY change for it to NOT be copied. Xcode 6 simply adds new and convenient UI for a practice that's been standard for over a decade. So yes, it does copy frameworks BY DEFAULT.
>> Examples of how Xcode facilitates this:
>
>
> This example exhibits explicit setting in Xcode project to copy selected frameworks into the bundle. But please remember you want this behavior to be default for Qmake (qbs?) Qt based app build. All I am saying this shouldn't be default.
We might be debating the meaning of "default". The default workflow should absolutely be to copy frameworks; I'm not saying that by default qmake should copy every framework into every app bundle without being told. Hence why QMAKE_EMBEDDED_FRAMEWORKS would be a user-set property. Much like qmake doesn't automatically invent values for SOURCES but you still need to set it to create anything useful.
There is a very simple solution to this problem. I and the majority of developers do this:
QMAKE_EMBEDDED_FRAMEWORKS = QtCore QtGui QtWidgets
You do this:
CONFIG(release, debug|release):QMAKE_EMBEDDED_FRAMEWORKS = QtCore QtGui QtWidgets
QMAKE_LFLAGS_DEBUG += -Wl,-rpath,$$QT_INSTALL_LIBS
>> This is not a novel idea I just came up with. This has been the standard workflow on OS X for over a decade.
>
> I am not arguing with that. I am just arguing with proposed default behavior.
>
> I am perfectly okay with ability to copy frameworks on build if it is requested by developer via CONFIG += bundle_on_build or whatever. But I am against doing it by default. I am running SSD on my both iMac & MBP since a while, but not anyone does.
I'm not running on an SSD and I have the slowest MacBook Pro imaginable (2008). I can assure you there is no performance degradation whatsoever when copying frameworks as part of the standard workflow. Also, like I said before... QMAKE_EMBEDDED_FRAMEWORKS. A CONFIG option is not necessary because if you don't want to copy things, simply don't set QMAKE_EMBEDDED_FRAMEWORKS, or set it for release configuration only.
> Please note that there is also some reasoning behind Copy Files Xcode build step option "Copy only when installing".
Which is unchecked by default and no one seems to use it. Either way I can assure you the reason for this setting was NOT a performance optimization for copying frameworks, in part because older versions of Xcode might not have actually set DYLD_LIBRARY_PATH/DYLD_FRAMEWORK_PATH.
>> The whole point of @rpath is to enable this improvement in workflow. By itself there is no point in adding it other than *slightly* simplifying some macdeployqt code.
>
> Again, I am not against having a switch to do what you tell during build time. But for other users sake I don't want to make it default.
For other users' sake we DO want to make it default. The workflows you want are foreign to every Mac developer out there.
>> Apologies for parroting, but... you are in fact wrong. I've JUST tested this and Xcode does in fact set many environment variables when running an application. I've added NSLog(@"%@", [[NSProcessInfo processInfo] environment]);
>
> Apologies taken. Especially having that I was wrong. Indeed Xcode does that for sake of frameworks being part of project that are yet not installed. Yet DYLD_FRAMEWORK_PATH serves bit different purpose here, it makes the app work even there is no framework yet in /Library/Frameworks.
>
>> I work with Xcode on a daily basis building native Cocoa apps. (…)
>
> I am sorry, it wasn't my intention to negate your skills or whatsoever. I am really happy that you take part of this discussion.
>
>> Point being? The system default DYLIB_INSTALL_NAME_BASE for frameworks in the Xcode build system happens to be /Library/Frameworks. For new projects it should be set to @rpath (and the IDE does this when creating a new target). Nothing to see here.
>
> Can you please check this, because I checked it twice and neither creating new Cocoa framework project nor adding new Cocoa framework target resulted in having @rpath as install name.
New in Xcode 6.
> So altogether I think best solution is to symlink all needed frameworks on build. This removes need to make proper change in Qt Creator to use DYLD_FRAMEWORK_PATH, makes app work via Dock/Finder even it is not yet completely bundled.
I'm curious why you think this will have a noticeable impact on performance. It is an unnecessary over-complication that actually leads to more bugs. Because this suggestion is contrary to every standard of Mac development, I will not accept this as a valid argument until you can provide benchmarks proving that there is a significant performance degradation.
Secondly, you're forgetting about user frameworks. Unless you copy those to the bundle at build time as well, currently, with Qt 5, your application WILL NOT work when launched via Dock/Finder. The fact that it works now for *some* apps is, like I mentioned before, a side effect.
> Such symlink may be relative (if possible) so all Qt examples may be built but not "bundled", therefore their will use single copies of frameworks.
>
> I am perfectly okay to have "bundle_on_build" config which makes "make" behave as "make" & "make deploy" so it will satisfy your needs.
>
> WDYT?
>
> Regards,
> --
> Adam
--
Jake Petroules - jake.petroules at petroules.com
Chief Technology Officer - Petroules Corporation
From aleixpol at kde.org Mon Aug 4 02:02:00 2014
From: aleixpol at kde.org (Aleix Pol)
Date: Mon, 4 Aug 2014 01:02:00 +0200
Subject: [Development] QZipReader and QZipWriter
In-Reply-To: <213CA41A-1DF5-44AE-B93F-3FBB19943F39@gmx.de>
References:
<1727845.pJKJQYuIsM@tjmaciei-mobl4>
<20140731083056.GC4927@ugly.fritz.box>
<21985962.1jl2FyDo8B@tjmaciei-mobl4>
<213CA41A-1DF5-44AE-B93F-3FBB19943F39@gmx.de>
Message-ID:
On Sun, Aug 3, 2014 at 12:08 AM, Gunnar Roth wrote:
>
> Am 02.08.2014 um 18:14 schrieb Thiago Macieira >:
>
>
> And to be honest, while convenient, this is not a must-have feature. With
> my
> OSS hat on, I would say (L)GPL-averse customers could be served right by
> their
> aversion by having one fewer solution.
> --
>
> As someone who has a qt commercial license for some years now and
> advocated the use of qt commercial internally,
> so we have bought nearly about some dozen licenses, this is interesting to
> hear , what kind of appreciation we get for paying thousands of euros each
> year. Nice…no so.
>
> regards,
> Gunnar
>
Hi Gunnar,
KDE has made a huge effort to make sure any Qt user can take advantage of
KArchive. We are very interested in having it used in very different
projects, from open and closed-source nature. If there's any thought
against, I'll be happy to know, because I don't understand.
Regards,
Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From aleixpol at kde.org Mon Aug 4 02:02:00 2014
From: aleixpol at kde.org (Aleix Pol)
Date: Mon, 4 Aug 2014 01:02:00 +0200
Subject: [Development] QZipReader and QZipWriter
In-Reply-To: <213CA41A-1DF5-44AE-B93F-3FBB19943F39@gmx.de>
References:
<1727845.pJKJQYuIsM@tjmaciei-mobl4>
<20140731083056.GC4927@ugly.fritz.box>
<21985962.1jl2FyDo8B@tjmaciei-mobl4>
<213CA41A-1DF5-44AE-B93F-3FBB19943F39@gmx.de>
Message-ID:
On Sun, Aug 3, 2014 at 12:08 AM, Gunnar Roth wrote:
>
> Am 02.08.2014 um 18:14 schrieb Thiago Macieira >:
>
>
> And to be honest, while convenient, this is not a must-have feature. With
> my
> OSS hat on, I would say (L)GPL-averse customers could be served right by
> their
> aversion by having one fewer solution.
> --
>
> As someone who has a qt commercial license for some years now and
> advocated the use of qt commercial internally,
> so we have bought nearly about some dozen licenses, this is interesting to
> hear , what kind of appreciation we get for paying thousands of euros each
> year. Nice…no so.
>
> regards,
> Gunnar
>
Hi Gunnar,
KDE has made a huge effort to make sure any Qt user can take advantage of
KArchive. We are very interested in having it used in very different
projects, from open and closed-source nature. If there's any thought
against, I'll be happy to know, because I don't understand.
Regards,
Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ono at java.pl Mon Aug 4 03:17:34 2014
From: ono at java.pl (Adam Strzelecki)
Date: Mon, 4 Aug 2014 02:17:34 +0200
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To:
References: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
<53DBF1F5.7030401@tungware.se>
<4BF629EA-C68A-434B-A042-27EA671D92FF@petroules.com>
<4A3F9CEC-5459-4F42-9426-875D0D8B7E69@petroules.com>
<739BD054-A176-4991-8928-CED4493BF0F4@java.pl>
Message-ID:
> In Xcode 6, when you create a new framework target, the first application target in the project is automatically selected for "embed in bundle" which you'd have to EXPLICITLY change for it to NOT be copied. Xcode 6 simply adds new and convenient UI for a practice that's been standard for over a decade. So yes, it does copy frameworks BY DEFAULT.
OMG, we were talking about two different Xcode versions. I am talking about Xcode 5 that does behave like I described, you are talking about Xcode 6 that indeed defaults to @rpath like you have described. But Xcode 6 is not final release, it is beta, so this may stay or not.
It makes completely sense to bundle project libraries into project application bundles. Yet Qt isn't part of your project, it is an external dependency, your project does not build Qt, it just links to it.
Does Xcode 6 automatically bundle an external framework added as dependency to your project, NO it does not.
> There is a very simple solution to this problem. I and the majority of developers do this:
> QMAKE_EMBEDDED_FRAMEWORKS = QtCore QtGui QtWidgets
"would" is more adequate here because we are talking about some possible setting not existing one.
> I'm not running on an SSD and I have the slowest MacBook Pro imaginable (2008). I can assure you there is no performance degradation whatsoever when copying frameworks as part of the standard workflow. Also, like I said before... QMAKE_EMBEDDED_FRAMEWORKS. A CONFIG option is not necessary because if you don't want to copy things, simply don't set QMAKE_EMBEDDED_FRAMEWORKS, or set it for release configuration only.
Sorry it doesn't make sense to me. Why would you like to specify which frameworks are to be copied if this is figured out by macdeployqt today automatically. Why someone would like to copy just some of the frameworks not all used by the application.
Reasonable choice it just to bundle when building ("make") or manually ("make && make bundle").
> For other users' sake we DO want to make it default. The workflows you want are foreign to every Mac developer out there.
Because Xcode 6 which is beta (not stable, may change, etc. etc.) does bundle frameworks which are part of the project? Qt are not part of your project, these are external dependencies. Xcode 6 won't bundle them if you add them as dependencies.
> New in Xcode 6.
You should say that at the very beginning.
> I'm curious why you think this will have a noticeable impact on performance. It is an unnecessary over-complication that actually leads to more bugs. Because this suggestion is contrary to every standard of Mac development, I will not accept this as a valid argument until you can provide benchmarks proving that there is a significant performance degradation.
Minimal GUI app's Qt frameworks weight around 20MB in release and 40MB in debug versions. This may be not much, but considering the fact app itself may be just few hundred KB this makes a difference. It won't have noticeable impact, unless you are working on network drives or whatever like that.
Altogether we have just different opinions about single post-process step, but we both agree we need @rpath working, we agree that bundling should be mark of qmake. So I believe decision whether bundle by default or not should be taken by Qt project maintainers, that's it. But we should have both options supported.
If we had BTRFS with COW this would be obvious choice, but we don't.
Regards,
--
Adam
From ono at java.pl Mon Aug 4 03:17:34 2014
From: ono at java.pl (Adam Strzelecki)
Date: Mon, 4 Aug 2014 02:17:34 +0200
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To:
References: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
<53DBF1F5.7030401@tungware.se>
<4BF629EA-C68A-434B-A042-27EA671D92FF@petroules.com>
<4A3F9CEC-5459-4F42-9426-875D0D8B7E69@petroules.com>
<739BD054-A176-4991-8928-CED4493BF0F4@java.pl>
Message-ID:
> In Xcode 6, when you create a new framework target, the first application target in the project is automatically selected for "embed in bundle" which you'd have to EXPLICITLY change for it to NOT be copied. Xcode 6 simply adds new and convenient UI for a practice that's been standard for over a decade. So yes, it does copy frameworks BY DEFAULT.
OMG, we were talking about two different Xcode versions. I am talking about Xcode 5 that does behave like I described, you are talking about Xcode 6 that indeed defaults to @rpath like you have described. But Xcode 6 is not final release, it is beta, so this may stay or not.
It makes completely sense to bundle project libraries into project application bundles. Yet Qt isn't part of your project, it is an external dependency, your project does not build Qt, it just links to it.
Does Xcode 6 automatically bundle an external framework added as dependency to your project, NO it does not.
> There is a very simple solution to this problem. I and the majority of developers do this:
> QMAKE_EMBEDDED_FRAMEWORKS = QtCore QtGui QtWidgets
"would" is more adequate here because we are talking about some possible setting not existing one.
> I'm not running on an SSD and I have the slowest MacBook Pro imaginable (2008). I can assure you there is no performance degradation whatsoever when copying frameworks as part of the standard workflow. Also, like I said before... QMAKE_EMBEDDED_FRAMEWORKS. A CONFIG option is not necessary because if you don't want to copy things, simply don't set QMAKE_EMBEDDED_FRAMEWORKS, or set it for release configuration only.
Sorry it doesn't make sense to me. Why would you like to specify which frameworks are to be copied if this is figured out by macdeployqt today automatically. Why someone would like to copy just some of the frameworks not all used by the application.
Reasonable choice it just to bundle when building ("make") or manually ("make && make bundle").
> For other users' sake we DO want to make it default. The workflows you want are foreign to every Mac developer out there.
Because Xcode 6 which is beta (not stable, may change, etc. etc.) does bundle frameworks which are part of the project? Qt are not part of your project, these are external dependencies. Xcode 6 won't bundle them if you add them as dependencies.
> New in Xcode 6.
You should say that at the very beginning.
> I'm curious why you think this will have a noticeable impact on performance. It is an unnecessary over-complication that actually leads to more bugs. Because this suggestion is contrary to every standard of Mac development, I will not accept this as a valid argument until you can provide benchmarks proving that there is a significant performance degradation.
Minimal GUI app's Qt frameworks weight around 20MB in release and 40MB in debug versions. This may be not much, but considering the fact app itself may be just few hundred KB this makes a difference. It won't have noticeable impact, unless you are working on network drives or whatever like that.
Altogether we have just different opinions about single post-process step, but we both agree we need @rpath working, we agree that bundling should be mark of qmake. So I believe decision whether bundle by default or not should be taken by Qt project maintainers, that's it. But we should have both options supported.
If we had BTRFS with COW this would be obvious choice, but we don't.
Regards,
--
Adam
From jake.petroules at petroules.com Mon Aug 4 05:30:06 2014
From: jake.petroules at petroules.com (Jake Petroules)
Date: Sun, 3 Aug 2014 22:30:06 -0400
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To:
References: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
<53DBF1F5.7030401@tungware.se>
<4BF629EA-C68A-434B-A042-27EA671D92FF@petroules.com>
<4A3F9CEC-5459-4F42-9426-875D0D8B7E69@petroules.com>
<739BD054-A176-4991-8928-CED4493BF0F4@java.pl>
Message-ID:
On 2014-08-03, at 08:17 PM, Adam Strzelecki wrote:
>> In Xcode 6, when you create a new framework target, the first application target in the project is automatically selected for "embed in bundle" which you'd have to EXPLICITLY change for it to NOT be copied. Xcode 6 simply adds new and convenient UI for a practice that's been standard for over a decade. So yes, it does copy frameworks BY DEFAULT.
>
> OMG, we were talking about two different Xcode versions. I am talking about Xcode 5 that does behave like I described, you are talking about Xcode 6 that indeed defaults to @rpath like you have described. But Xcode 6 is not final release, it is beta, so this may stay or not.
Don't hold your breath.
> It makes completely sense to bundle project libraries into project application bundles. Yet Qt isn't part of your project, it is an external dependency, your project does not build Qt, it just links to it.
As Qt is not a system library it's as much a part of your project as anything. For all you know, some project out there bundles Qt with its source and builds it along with everything else. Not a wrong thing to do, especially if that project relies on specific customizations. Whether a particular target is built within your source tree or not is rather irrelevant to whether it needs to be copied into your application bundle. Unless it's a system library that exists on all installations of the OS, it needs to be copied.
> Does Xcode 6 automatically bundle an external framework added as dependency to your project, NO it does not.
>
>> There is a very simple solution to this problem. I and the majority of developers do this:
>> QMAKE_EMBEDDED_FRAMEWORKS = QtCore QtGui QtWidgets
>
> "would" is more adequate here because we are talking about some possible setting not existing one.
>
>> I'm not running on an SSD and I have the slowest MacBook Pro imaginable (2008). I can assure you there is no performance degradation whatsoever when copying frameworks as part of the standard workflow. Also, like I said before... QMAKE_EMBEDDED_FRAMEWORKS. A CONFIG option is not necessary because if you don't want to copy things, simply don't set QMAKE_EMBEDDED_FRAMEWORKS, or set it for release configuration only.
>
> Sorry it doesn't make sense to me. Why would you like to specify which frameworks are to be copied if this is figured out by macdeployqt today automatically. Why someone would like to copy just some of the frameworks not all used by the application.
Because macdeployqt needs to go away. Once the Qt SDK is built correctly, it becomes a useless tool and can be deleted. That's not to say qmake can't automatically set the value of QMAKE_EMBEDDED_FRAMEWORKS. You can then add additional frameworks to it as necessary, i.e. QMAKE_EMBEDDED_FRAMEWORKS += /Library/Frameworks/Sparkle.framework /Library/Frameworks/Growl.framework
> Reasonable choice it just to bundle when building ("make") or manually ("make && make bundle").
>
>> For other users' sake we DO want to make it default. The workflows you want are foreign to every Mac developer out there.
>
> Because Xcode 6 which is beta (not stable, may change, etc. etc.) does bundle frameworks which are part of the project? Qt are not part of your project, these are external dependencies. Xcode 6 won't bundle them if you add them as dependencies.
Don't try to use its beta status as a way of trying to argue against the correct solution. The only reason I mentioned Xcode 6 functionality was to place additional emphasis on this is how OS X and iOS applications are built in the real world. Regardless of additional conveniences that Xcode 6 may or may not add, my argument is solid on its own.
>> New in Xcode 6.
>
> You should say that at the very beginning.
>
>> I'm curious why you think this will have a noticeable impact on performance. It is an unnecessary over-complication that actually leads to more bugs. Because this suggestion is contrary to every standard of Mac development, I will not accept this as a valid argument until you can provide benchmarks proving that there is a significant performance degradation.
>
> Minimal GUI app's Qt frameworks weight around 20MB in release and 40MB in debug versions. This may be not much, but considering the fact app itself may be just few hundred KB this makes a difference. It won't have noticeable impact, unless you are working on network drives or whatever like that.
Then if you admit it won't have noticeable impact, why are you continuing to argue against it? Try this experiment on your machine:
mkdir -p /tmp/experiments/Frameworks
mkdir -p /tmp/experiments/SDK
cd /tmp/experiments/SDK
mkdir QtCore.framework QtGui.framework QtNetwork.framework QtSvg.framework QtXml.framework QtWidgets.framework Frameworks
dd if=/dev/zero of=QtCore.framework/A bs=1024 count=10240
dd if=/dev/zero of=QtGui.framework/A bs=1024 count=10240
dd if=/dev/zero of=QtNetwork.framework/A bs=1024 count=10240
dd if=/dev/zero of=QtSvg.framework/A bs=1024 count=10240
dd if=/dev/zero of=QtXml.framework/A bs=1024 count=10240
dd if=/dev/zero of=QtWidgets.framework/A bs=1024 count=10240
cd ..
time rsync -a SDK/ Frameworks/
time rsync -a SDK/ Frameworks/
time rsync -a SDK/ Frameworks/
time rsync -a SDK/ Frameworks/
No sane implementation of the proposed QMAKE_EMBEDDED_FRAMEWORKS would blindly run cp -R every single time you build; that is ridiculous and I'm guessing that's what you think I am advocating. There are ways to optimize copying large numbers of files as you can clearly see based on rsync's performance.
If you run this experiment, you'll notice that the first call to rsync completes in maybe a few seconds (mine was 4.6 seconds). Each subsequent call is less than 0.06 seconds (60ms). I even duplicated the source frameworks 9 more times, raising the payload from something like a typical 60 MB to 600 MB. No Qt application bundles even close to 600 MB worth of Qt frameworks. Wonder how long it takes rsync to copy on rebuild? Still 0.06 seconds. +0.06 seconds rebuild time increase to copy 600 MB worth of Qt frameworks.
I even rscyned to a slow external hard drive to test the copying speed. Still only 0.07 seconds on average (and only 39 seconds cold - for 600 MB). Ok, let's even copy to a remote server outside my LAN to further demonstrate the point. 7.5 minutes cold copy. Understandable. But still only 0.8 seconds on average to warm-copy 600 MB to a remote server outside LAN.
There is no conceivable real world scenario where you can argue that copying frameworks to bundles as part of the standard build process is a significant enough performance impediment to seek alternate solutions, especially when said solution is already in universal use by the platform vendor.
So my solution adds MAYBE 5-30 seconds on average to a cold build (which is going to take on the order of minutes to hours anyways), and 60 MILLISECONDS to a rebuild. Why are we even debating the addition of 60 milliseconds?! Especially when it solves several much more important problems.
So, let's end this discussion and start focusing efforts towards building the solution.
> Altogether we have just different opinions about single post-process step, but we both agree we need @rpath working, we agree that bundling should be mark of qmake. So I believe decision whether bundle by default or not should be taken by Qt project maintainers, that's it. But we should have both options supported.
>
> If we had BTRFS with COW this would be obvious choice, but we don't.
This would not make any difference to the argument whatsoever. As I mentioned before, you have not provided any benchmarks. I have. Prove me wrong and we'll talk.
> Regards,
> --
> Adam
>
--
Jake Petroules - jake.petroules at petroules.com
Chief Technology Officer - Petroules Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jake.petroules at petroules.com Mon Aug 4 05:30:06 2014
From: jake.petroules at petroules.com (Jake Petroules)
Date: Sun, 3 Aug 2014 22:30:06 -0400
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To:
References: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
<53DBF1F5.7030401@tungware.se>
<4BF629EA-C68A-434B-A042-27EA671D92FF@petroules.com>
<4A3F9CEC-5459-4F42-9426-875D0D8B7E69@petroules.com>
<739BD054-A176-4991-8928-CED4493BF0F4@java.pl>
Message-ID:
On 2014-08-03, at 08:17 PM, Adam Strzelecki wrote:
>> In Xcode 6, when you create a new framework target, the first application target in the project is automatically selected for "embed in bundle" which you'd have to EXPLICITLY change for it to NOT be copied. Xcode 6 simply adds new and convenient UI for a practice that's been standard for over a decade. So yes, it does copy frameworks BY DEFAULT.
>
> OMG, we were talking about two different Xcode versions. I am talking about Xcode 5 that does behave like I described, you are talking about Xcode 6 that indeed defaults to @rpath like you have described. But Xcode 6 is not final release, it is beta, so this may stay or not.
Don't hold your breath.
> It makes completely sense to bundle project libraries into project application bundles. Yet Qt isn't part of your project, it is an external dependency, your project does not build Qt, it just links to it.
As Qt is not a system library it's as much a part of your project as anything. For all you know, some project out there bundles Qt with its source and builds it along with everything else. Not a wrong thing to do, especially if that project relies on specific customizations. Whether a particular target is built within your source tree or not is rather irrelevant to whether it needs to be copied into your application bundle. Unless it's a system library that exists on all installations of the OS, it needs to be copied.
> Does Xcode 6 automatically bundle an external framework added as dependency to your project, NO it does not.
>
>> There is a very simple solution to this problem. I and the majority of developers do this:
>> QMAKE_EMBEDDED_FRAMEWORKS = QtCore QtGui QtWidgets
>
> "would" is more adequate here because we are talking about some possible setting not existing one.
>
>> I'm not running on an SSD and I have the slowest MacBook Pro imaginable (2008). I can assure you there is no performance degradation whatsoever when copying frameworks as part of the standard workflow. Also, like I said before... QMAKE_EMBEDDED_FRAMEWORKS. A CONFIG option is not necessary because if you don't want to copy things, simply don't set QMAKE_EMBEDDED_FRAMEWORKS, or set it for release configuration only.
>
> Sorry it doesn't make sense to me. Why would you like to specify which frameworks are to be copied if this is figured out by macdeployqt today automatically. Why someone would like to copy just some of the frameworks not all used by the application.
Because macdeployqt needs to go away. Once the Qt SDK is built correctly, it becomes a useless tool and can be deleted. That's not to say qmake can't automatically set the value of QMAKE_EMBEDDED_FRAMEWORKS. You can then add additional frameworks to it as necessary, i.e. QMAKE_EMBEDDED_FRAMEWORKS += /Library/Frameworks/Sparkle.framework /Library/Frameworks/Growl.framework
> Reasonable choice it just to bundle when building ("make") or manually ("make && make bundle").
>
>> For other users' sake we DO want to make it default. The workflows you want are foreign to every Mac developer out there.
>
> Because Xcode 6 which is beta (not stable, may change, etc. etc.) does bundle frameworks which are part of the project? Qt are not part of your project, these are external dependencies. Xcode 6 won't bundle them if you add them as dependencies.
Don't try to use its beta status as a way of trying to argue against the correct solution. The only reason I mentioned Xcode 6 functionality was to place additional emphasis on this is how OS X and iOS applications are built in the real world. Regardless of additional conveniences that Xcode 6 may or may not add, my argument is solid on its own.
>> New in Xcode 6.
>
> You should say that at the very beginning.
>
>> I'm curious why you think this will have a noticeable impact on performance. It is an unnecessary over-complication that actually leads to more bugs. Because this suggestion is contrary to every standard of Mac development, I will not accept this as a valid argument until you can provide benchmarks proving that there is a significant performance degradation.
>
> Minimal GUI app's Qt frameworks weight around 20MB in release and 40MB in debug versions. This may be not much, but considering the fact app itself may be just few hundred KB this makes a difference. It won't have noticeable impact, unless you are working on network drives or whatever like that.
Then if you admit it won't have noticeable impact, why are you continuing to argue against it? Try this experiment on your machine:
mkdir -p /tmp/experiments/Frameworks
mkdir -p /tmp/experiments/SDK
cd /tmp/experiments/SDK
mkdir QtCore.framework QtGui.framework QtNetwork.framework QtSvg.framework QtXml.framework QtWidgets.framework Frameworks
dd if=/dev/zero of=QtCore.framework/A bs=1024 count=10240
dd if=/dev/zero of=QtGui.framework/A bs=1024 count=10240
dd if=/dev/zero of=QtNetwork.framework/A bs=1024 count=10240
dd if=/dev/zero of=QtSvg.framework/A bs=1024 count=10240
dd if=/dev/zero of=QtXml.framework/A bs=1024 count=10240
dd if=/dev/zero of=QtWidgets.framework/A bs=1024 count=10240
cd ..
time rsync -a SDK/ Frameworks/
time rsync -a SDK/ Frameworks/
time rsync -a SDK/ Frameworks/
time rsync -a SDK/ Frameworks/
No sane implementation of the proposed QMAKE_EMBEDDED_FRAMEWORKS would blindly run cp -R every single time you build; that is ridiculous and I'm guessing that's what you think I am advocating. There are ways to optimize copying large numbers of files as you can clearly see based on rsync's performance.
If you run this experiment, you'll notice that the first call to rsync completes in maybe a few seconds (mine was 4.6 seconds). Each subsequent call is less than 0.06 seconds (60ms). I even duplicated the source frameworks 9 more times, raising the payload from something like a typical 60 MB to 600 MB. No Qt application bundles even close to 600 MB worth of Qt frameworks. Wonder how long it takes rsync to copy on rebuild? Still 0.06 seconds. +0.06 seconds rebuild time increase to copy 600 MB worth of Qt frameworks.
I even rscyned to a slow external hard drive to test the copying speed. Still only 0.07 seconds on average (and only 39 seconds cold - for 600 MB). Ok, let's even copy to a remote server outside my LAN to further demonstrate the point. 7.5 minutes cold copy. Understandable. But still only 0.8 seconds on average to warm-copy 600 MB to a remote server outside LAN.
There is no conceivable real world scenario where you can argue that copying frameworks to bundles as part of the standard build process is a significant enough performance impediment to seek alternate solutions, especially when said solution is already in universal use by the platform vendor.
So my solution adds MAYBE 5-30 seconds on average to a cold build (which is going to take on the order of minutes to hours anyways), and 60 MILLISECONDS to a rebuild. Why are we even debating the addition of 60 milliseconds?! Especially when it solves several much more important problems.
So, let's end this discussion and start focusing efforts towards building the solution.
> Altogether we have just different opinions about single post-process step, but we both agree we need @rpath working, we agree that bundling should be mark of qmake. So I believe decision whether bundle by default or not should be taken by Qt project maintainers, that's it. But we should have both options supported.
>
> If we had BTRFS with COW this would be obvious choice, but we don't.
This would not make any difference to the argument whatsoever. As I mentioned before, you have not provided any benchmarks. I have. Prove me wrong and we'll talk.
> Regards,
> --
> Adam
>
--
Jake Petroules - jake.petroules at petroules.com
Chief Technology Officer - Petroules Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From Lars.Knoll at digia.com Mon Aug 4 09:02:51 2014
From: Lars.Knoll at digia.com (Knoll Lars)
Date: Mon, 4 Aug 2014 06:02:51 +0000
Subject: [Development] [docs/c++] How do we deal with the special member
functions (copy/move ctor/assignment operator, dtor, default ctor)
In-Reply-To: <3783897.zvvUg1BiLp@tjmaciei-mobl4>
References: <201408012316.40275.marc.mutz@kdab.com>
<3783897.zvvUg1BiLp@tjmaciei-mobl4>
Message-ID:
On 02/08/14 18:21, "Thiago Macieira" wrote:
>On Friday 01 August 2014 23:16:40 Marc Mutz wrote:
>> That leaves the question how to deal with the documentation for these
>> implicit members.
>
>Why do we have to document them in the first place? I hate having to
>write
>documentation for a destructor that simply says "frees resources
>associated
>with this object". That much is obvious: any self-respecting destructor
>will
>do that and the same applies to copy and move constructors.
>
>What we really want is to document which objects are copyable and which
>ones
>aren't. And that is very simple: any object with Q_DISABLE_COPY is not
>copyable, (almost) everything else is.
+1. I don’t see a reason to document implicitly generated methods. They
simply do what the C++ standard defines they should do.
Cheers,
Lars
From Lars.Knoll at digia.com Mon Aug 4 09:02:51 2014
From: Lars.Knoll at digia.com (Knoll Lars)
Date: Mon, 4 Aug 2014 06:02:51 +0000
Subject: [Development] [docs/c++] How do we deal with the special member
functions (copy/move ctor/assignment operator, dtor, default ctor)
In-Reply-To: <3783897.zvvUg1BiLp@tjmaciei-mobl4>
References: <201408012316.40275.marc.mutz@kdab.com>
<3783897.zvvUg1BiLp@tjmaciei-mobl4>
Message-ID:
On 02/08/14 18:21, "Thiago Macieira" wrote:
>On Friday 01 August 2014 23:16:40 Marc Mutz wrote:
>> That leaves the question how to deal with the documentation for these
>> implicit members.
>
>Why do we have to document them in the first place? I hate having to
>write
>documentation for a destructor that simply says "frees resources
>associated
>with this object". That much is obvious: any self-respecting destructor
>will
>do that and the same applies to copy and move constructors.
>
>What we really want is to document which objects are copyable and which
>ones
>aren't. And that is very simple: any object with Q_DISABLE_COPY is not
>copyable, (almost) everything else is.
+1. I don’t see a reason to document implicitly generated methods. They
simply do what the C++ standard defines they should do.
Cheers,
Lars
From gunnar.roth at gmx.de Mon Aug 4 09:36:37 2014
From: gunnar.roth at gmx.de (Gunnar Roth)
Date: Mon, 4 Aug 2014 08:36:37 +0200
Subject: [Development] QZipReader and QZipWriter
In-Reply-To:
References:
<1727845.pJKJQYuIsM@tjmaciei-mobl4>
<20140731083056.GC4927@ugly.fritz.box>
<21985962.1jl2FyDo8B@tjmaciei-mobl4>
<213CA41A-1DF5-44AE-B93F-3FBB19943F39@gmx.de>
Message-ID: <9DCA6824-0A56-49DE-A001-A591FDF612C5@gmx.de>
Hi,
sorry my comment has no relation to KArchive in special, I appreciate our efforts.
I was the attitude which let me maybe overreact. We could as well switch to LGPL and save a lot of money.
Never mind,
Gunnar
> Am 04.08.2014 um 01:02 schrieb Aleix Pol :
>
> On Sun, Aug 3, 2014 at 12:08 AM, Gunnar Roth wrote:
>
>> Am 02.08.2014 um 18:14 schrieb Thiago Macieira :
>>
>>
>> And to be honest, while convenient, this is not a must-have feature. With my
>> OSS hat on, I would say (L)GPL-averse customers could be served right by their
>> aversion by having one fewer solution.
>> --
> As someone who has a qt commercial license for some years now and advocated the use of qt commercial internally,
> so we have bought nearly about some dozen licenses, this is interesting to hear , what kind of appreciation we get for paying thousands of euros each year. Nice…no so.
>
> regards,
> Gunnar
>
> Hi Gunnar,
> KDE has made a huge effort to make sure any Qt user can take advantage of KArchive. We are very interested in having it used in very different projects, from open and closed-source nature. If there's any thought against, I'll be happy to know, because I don't understand.
>
> Regards,
> Aleix
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From gunnar.roth at gmx.de Mon Aug 4 09:36:37 2014
From: gunnar.roth at gmx.de (Gunnar Roth)
Date: Mon, 4 Aug 2014 08:36:37 +0200
Subject: [Development] QZipReader and QZipWriter
In-Reply-To:
References:
<1727845.pJKJQYuIsM@tjmaciei-mobl4>
<20140731083056.GC4927@ugly.fritz.box>
<21985962.1jl2FyDo8B@tjmaciei-mobl4>
<213CA41A-1DF5-44AE-B93F-3FBB19943F39@gmx.de>
Message-ID: <9DCA6824-0A56-49DE-A001-A591FDF612C5@gmx.de>
Hi,
sorry my comment has no relation to KArchive in special, I appreciate our efforts.
I was the attitude which let me maybe overreact. We could as well switch to LGPL and save a lot of money.
Never mind,
Gunnar
> Am 04.08.2014 um 01:02 schrieb Aleix Pol :
>
> On Sun, Aug 3, 2014 at 12:08 AM, Gunnar Roth wrote:
>
>> Am 02.08.2014 um 18:14 schrieb Thiago Macieira :
>>
>>
>> And to be honest, while convenient, this is not a must-have feature. With my
>> OSS hat on, I would say (L)GPL-averse customers could be served right by their
>> aversion by having one fewer solution.
>> --
> As someone who has a qt commercial license for some years now and advocated the use of qt commercial internally,
> so we have bought nearly about some dozen licenses, this is interesting to hear , what kind of appreciation we get for paying thousands of euros each year. Nice…no so.
>
> regards,
> Gunnar
>
> Hi Gunnar,
> KDE has made a huge effort to make sure any Qt user can take advantage of KArchive. We are very interested in having it used in very different projects, from open and closed-source nature. If there's any thought against, I'll be happy to know, because I don't understand.
>
> Regards,
> Aleix
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From sumedha.widyadharma at basyskom.com Mon Aug 4 09:57:25 2014
From: sumedha.widyadharma at basyskom.com (Sumedha Widyadharma)
Date: Mon, 04 Aug 2014 08:57:25 +0200
Subject: [Development] Relative paths in EXAMPLE_FILES in .pro files
In-Reply-To: <36078478.Agox8kLvH2@tjmaciei-mobl4>
References: <53DBA7FC.5070600@basyskom.com>
<36078478.Agox8kLvH2@tjmaciei-mobl4>
Message-ID: <53DF2ED5.4060700@basyskom.com>
Morning,
EXAMPLE_FILES contains a list of additional example files for a project.
The files referenced in the variable will be installed by qmake to the
appropriate examples destination.
See: mkspecs/features/qt_example_installs.prf
On 08/02/2014 06:19 PM, Thiago Macieira wrote:
> On Friday 01 August 2014 16:45:16 Sumedha Widyadharma wrote:
>> Hi,
>>
>> This seems to be forbidden in a .pro file:
>>
>> EXAMPLE_FILES += ../some/file
>>
>> what is the rationale behind not allowing this?
>
> Why is it forbidden?
The file is simply not installed as an example file.
It is _silently_ dropped.
The rationale behind not allowing .. is to have examples self-contained,
this I get. Grouping examples accordingly is the solution here.
But dropping them silently by default seems very user-unfriendly.
>
>> It is silently dropped, you have to enable CONFIG+=check_examples to get
>> a notice about this. Why is that?
>
> About what?
When you set CONFIG+=check_examples you get a message when a file
conatining '..' is referenced as an example file.
Example:
Project MESSAGE: Notice:
/home/swid/src/qwebchannel/examples/qwebchannel/nodejs/nodejs.pro refers
to ../../../src/webchannel/qwebchannel.js
>
> You can assign any value to any variable you want in qmake. Whether you make
> use of the variable or not, it's up to you.
This variable is used internally.
>
>> Shouldn't it always warn the user?
>
> About what?
>
About dropping an example file due to having non self-contained paths.
Mit freundlichen Grüßen,
Sumedha Widyadharma
--
Sumedha Widyadharma
System Integrator
basysKom GmbH
Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany
Tel : +49 6151 870 589 128 | Fax: +49 6151 870 589 199
sumedha.widyadharma at basyskom.com | www.basyskom.com
Handelsregister: Darmstadt HRB 9352
Geschäftsführung: Eva Brucherseifer, Heike Ziegler
From sumedha.widyadharma at basyskom.com Mon Aug 4 09:57:25 2014
From: sumedha.widyadharma at basyskom.com (Sumedha Widyadharma)
Date: Mon, 04 Aug 2014 08:57:25 +0200
Subject: [Development] Relative paths in EXAMPLE_FILES in .pro files
In-Reply-To: <36078478.Agox8kLvH2@tjmaciei-mobl4>
References: <53DBA7FC.5070600@basyskom.com>
<36078478.Agox8kLvH2@tjmaciei-mobl4>
Message-ID: <53DF2ED5.4060700@basyskom.com>
Morning,
EXAMPLE_FILES contains a list of additional example files for a project.
The files referenced in the variable will be installed by qmake to the
appropriate examples destination.
See: mkspecs/features/qt_example_installs.prf
On 08/02/2014 06:19 PM, Thiago Macieira wrote:
> On Friday 01 August 2014 16:45:16 Sumedha Widyadharma wrote:
>> Hi,
>>
>> This seems to be forbidden in a .pro file:
>>
>> EXAMPLE_FILES += ../some/file
>>
>> what is the rationale behind not allowing this?
>
> Why is it forbidden?
The file is simply not installed as an example file.
It is _silently_ dropped.
The rationale behind not allowing .. is to have examples self-contained,
this I get. Grouping examples accordingly is the solution here.
But dropping them silently by default seems very user-unfriendly.
>
>> It is silently dropped, you have to enable CONFIG+=check_examples to get
>> a notice about this. Why is that?
>
> About what?
When you set CONFIG+=check_examples you get a message when a file
conatining '..' is referenced as an example file.
Example:
Project MESSAGE: Notice:
/home/swid/src/qwebchannel/examples/qwebchannel/nodejs/nodejs.pro refers
to ../../../src/webchannel/qwebchannel.js
>
> You can assign any value to any variable you want in qmake. Whether you make
> use of the variable or not, it's up to you.
This variable is used internally.
>
>> Shouldn't it always warn the user?
>
> About what?
>
About dropping an example file due to having non self-contained paths.
Mit freundlichen Grüßen,
Sumedha Widyadharma
--
Sumedha Widyadharma
System Integrator
basysKom GmbH
Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany
Tel : +49 6151 870 589 128 | Fax: +49 6151 870 589 199
sumedha.widyadharma at basyskom.com | www.basyskom.com
Handelsregister: Darmstadt HRB 9352
Geschäftsführung: Eva Brucherseifer, Heike Ziegler
From marc.mutz at kdab.com Mon Aug 4 10:31:12 2014
From: marc.mutz at kdab.com (Marc Mutz)
Date: Mon, 4 Aug 2014 09:31:12 +0200
Subject: [Development] [docs/c++] How do we deal with the special member
functions (copy/move ctor/assignment operator, dtor, default ctor)
In-Reply-To:
References: <201408012316.40275.marc.mutz@kdab.com>
<3783897.zvvUg1BiLp@tjmaciei-mobl4>
Message-ID: <201408040931.12074.marc.mutz@kdab.com>
On Monday 04 August 2014 08:02:51 Knoll Lars wrote:
> On 02/08/14 18:21, "Thiago Macieira" wrote:
> >On Friday 01 August 2014 23:16:40 Marc Mutz wrote:
> >> That leaves the question how to deal with the documentation for these
> >> implicit members.
> >
> >Why do we have to document them in the first place? I hate having to
> >write
> >documentation for a destructor that simply says "frees resources
> >associated
> >with this object". That much is obvious: any self-respecting destructor
> >will
> >do that and the same applies to copy and move constructors.
> >
> >What we really want is to document which objects are copyable and which
> >ones
> >aren't. And that is very simple: any object with Q_DISABLE_COPY is not
> >copyable, (almost) everything else is.
>
> +1. I don’t see a reason to document implicitly generated methods. They
> simply do what the C++ standard defines they should do.
Ok, fair enough, but how, then, is a user-defined special member function
(where user = Qt developers) different, assuming, of course, that the user-
defined copy ctor actually copies...? It's an implementation detail whether the
implicit version works or whether a user implementation is necessary.. By
documenting one and not the other, we either leak that information, or make
new C++ users think that some classes - that are - aren't copyable.
Worse: unless you look at the header file, there's no way to predict whether
the implicitly declared, say, copy constructor is deleted or defaulted. And
it's not as if Q_DISABLE_COPY generates any documentation.
So maybe the real questions is, as Thiago said, how to document whether a
class is a value class or polymorphic (though, of course, there are more than
these two: move-only classes, RAII classes (with some overlap between the two,
etc)).
\valueclass
\polymorphic
\raii
\move-only
Or just
\implicitdefaultctor
\impicitcopyctor
\implicitmovector
\implicitdtor
\implicitcopyassignment \____> \implicitassignment
\implicitmoveassignment /
?
--
Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin
Marc Mutz | Senior 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
From marc.mutz at kdab.com Mon Aug 4 10:31:12 2014
From: marc.mutz at kdab.com (Marc Mutz)
Date: Mon, 4 Aug 2014 09:31:12 +0200
Subject: [Development] [docs/c++] How do we deal with the special member
functions (copy/move ctor/assignment operator, dtor, default ctor)
In-Reply-To:
References: <201408012316.40275.marc.mutz@kdab.com>
<3783897.zvvUg1BiLp@tjmaciei-mobl4>
Message-ID: <201408040931.12074.marc.mutz@kdab.com>
On Monday 04 August 2014 08:02:51 Knoll Lars wrote:
> On 02/08/14 18:21, "Thiago Macieira" wrote:
> >On Friday 01 August 2014 23:16:40 Marc Mutz wrote:
> >> That leaves the question how to deal with the documentation for these
> >> implicit members.
> >
> >Why do we have to document them in the first place? I hate having to
> >write
> >documentation for a destructor that simply says "frees resources
> >associated
> >with this object". That much is obvious: any self-respecting destructor
> >will
> >do that and the same applies to copy and move constructors.
> >
> >What we really want is to document which objects are copyable and which
> >ones
> >aren't. And that is very simple: any object with Q_DISABLE_COPY is not
> >copyable, (almost) everything else is.
>
> +1. I don’t see a reason to document implicitly generated methods. They
> simply do what the C++ standard defines they should do.
Ok, fair enough, but how, then, is a user-defined special member function
(where user = Qt developers) different, assuming, of course, that the user-
defined copy ctor actually copies...? It's an implementation detail whether the
implicit version works or whether a user implementation is necessary.. By
documenting one and not the other, we either leak that information, or make
new C++ users think that some classes - that are - aren't copyable.
Worse: unless you look at the header file, there's no way to predict whether
the implicitly declared, say, copy constructor is deleted or defaulted. And
it's not as if Q_DISABLE_COPY generates any documentation.
So maybe the real questions is, as Thiago said, how to document whether a
class is a value class or polymorphic (though, of course, there are more than
these two: move-only classes, RAII classes (with some overlap between the two,
etc)).
\valueclass
\polymorphic
\raii
\move-only
Or just
\implicitdefaultctor
\impicitcopyctor
\implicitmovector
\implicitdtor
\implicitcopyassignment \____> \implicitassignment
\implicitmoveassignment /
?
--
Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin
Marc Mutz | Senior 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
From samuel.gaist at edeltech.ch Mon Aug 4 10:33:28 2014
From: samuel.gaist at edeltech.ch (Samuel Gaist)
Date: Mon, 4 Aug 2014 09:33:28 +0200
Subject: [Development] My availability
In-Reply-To:
References: <3218805.C81890yfld@hal>
Message-ID: <03D54CF2-284F-41AD-A568-B911CADAB4D5@edeltech.ch>
Hi Stephen,
Thanks for the reviewing and help !
Since you'll have less time, will you keep the Model/View maintainer role ?
On 16 juil. 2014, at 15:49, Robert Knight wrote:
> Hi Stephen,
>
> Thanks for all your contributions over the years. Up to anything
> interesting next?
>
> On 16 July 2014 14:25, Stephen Kelly wrote:
>>
>> Hi,
>>
>> After 5 years, my time at KDAB is coming to an end, and I'm going to have less
>> time for Qt development. I'll still be available for reviews.
>>
>> I'll be staying in Berlin, so you may still see me around sometimes.
>>
>> Thanks,
>>
>> --
>> Join us at Qt Developer Days 2014 in Berlin! - https://devdays.kdab.com
>>
>> 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
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
From samuel.gaist at edeltech.ch Mon Aug 4 10:33:28 2014
From: samuel.gaist at edeltech.ch (Samuel Gaist)
Date: Mon, 4 Aug 2014 09:33:28 +0200
Subject: [Development] My availability
In-Reply-To:
References: <3218805.C81890yfld@hal>
Message-ID: <03D54CF2-284F-41AD-A568-B911CADAB4D5@edeltech.ch>
Hi Stephen,
Thanks for the reviewing and help !
Since you'll have less time, will you keep the Model/View maintainer role ?
On 16 juil. 2014, at 15:49, Robert Knight wrote:
> Hi Stephen,
>
> Thanks for all your contributions over the years. Up to anything
> interesting next?
>
> On 16 July 2014 14:25, Stephen Kelly wrote:
>>
>> Hi,
>>
>> After 5 years, my time at KDAB is coming to an end, and I'm going to have less
>> time for Qt development. I'll still be available for reviews.
>>
>> I'll be staying in Berlin, so you may still see me around sometimes.
>>
>> Thanks,
>>
>> --
>> Join us at Qt Developer Days 2014 in Berlin! - https://devdays.kdab.com
>>
>> 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
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
From oswald.buddenhagen at digia.com Mon Aug 4 11:59:05 2014
From: oswald.buddenhagen at digia.com (Oswald Buddenhagen)
Date: Mon, 4 Aug 2014 10:59:05 +0200
Subject: [Development] QZipReader and QZipWriter
In-Reply-To: <9DCA6824-0A56-49DE-A001-A591FDF612C5@gmx.de>
References:
<1727845.pJKJQYuIsM@tjmaciei-mobl4>
<20140731083056.GC4927@ugly.fritz.box>
<21985962.1jl2FyDo8B@tjmaciei-mobl4>
<213CA41A-1DF5-44AE-B93F-3FBB19943F39@gmx.de>
<9DCA6824-0A56-49DE-A001-A591FDF612C5@gmx.de>
Message-ID: <20140804085905.GA27299@troll08.it.local>
On Mon, Aug 04, 2014 at 08:36:37AM +0200, Gunnar Roth wrote:
> sorry my comment has no relation to KArchive in special, I appreciate
> [y]our efforts. I was the attitude which let me maybe overreact. We
> could as well switch to LGPL and save a lot of money.
>
this is the _contributor_ _community_ mailing list. pay some attention
to the email addresses people post from before you even think of drawing
conclusions regarding _business_ attitudes.
also, "lgpl-averse" is quite a different thing from "commercial-affine".
From oswald.buddenhagen at digia.com Mon Aug 4 11:59:05 2014
From: oswald.buddenhagen at digia.com (Oswald Buddenhagen)
Date: Mon, 4 Aug 2014 10:59:05 +0200
Subject: [Development] QZipReader and QZipWriter
In-Reply-To: <9DCA6824-0A56-49DE-A001-A591FDF612C5@gmx.de>
References:
<1727845.pJKJQYuIsM@tjmaciei-mobl4>
<20140731083056.GC4927@ugly.fritz.box>
<21985962.1jl2FyDo8B@tjmaciei-mobl4>
<213CA41A-1DF5-44AE-B93F-3FBB19943F39@gmx.de>
<9DCA6824-0A56-49DE-A001-A591FDF612C5@gmx.de>
Message-ID: <20140804085905.GA27299@troll08.it.local>
On Mon, Aug 04, 2014 at 08:36:37AM +0200, Gunnar Roth wrote:
> sorry my comment has no relation to KArchive in special, I appreciate
> [y]our efforts. I was the attitude which let me maybe overreact. We
> could as well switch to LGPL and save a lot of money.
>
this is the _contributor_ _community_ mailing list. pay some attention
to the email addresses people post from before you even think of drawing
conclusions regarding _business_ attitudes.
also, "lgpl-averse" is quite a different thing from "commercial-affine".
From oswald.buddenhagen at digia.com Mon Aug 4 12:11:29 2014
From: oswald.buddenhagen at digia.com (Oswald Buddenhagen)
Date: Mon, 4 Aug 2014 11:11:29 +0200
Subject: [Development] Relative paths in EXAMPLE_FILES in .pro files
In-Reply-To: <53DBA7FC.5070600@basyskom.com>
References: <53DBA7FC.5070600@basyskom.com>
Message-ID: <20140804091129.GB27299@troll08.it.local>
On Fri, Aug 01, 2014 at 04:45:16PM +0200, Sumedha Widyadharma wrote:
> It is silently dropped, you have to enable CONFIG+=check_examples to
> get a notice about this. Why is that?
>
> Shouldn't it always warn the user?
>
there are some false positives which i found non-trivial to avoid
cleanly, so i opted for the silent default. as the "user" is in this
case the developer, and any non-trivial buildsystem-related changes
should be reviewed by me anyway, this seemed like a sensible choice.
back then. ^^
From oswald.buddenhagen at digia.com Mon Aug 4 12:11:29 2014
From: oswald.buddenhagen at digia.com (Oswald Buddenhagen)
Date: Mon, 4 Aug 2014 11:11:29 +0200
Subject: [Development] Relative paths in EXAMPLE_FILES in .pro files
In-Reply-To: <53DBA7FC.5070600@basyskom.com>
References: <53DBA7FC.5070600@basyskom.com>
Message-ID: <20140804091129.GB27299@troll08.it.local>
On Fri, Aug 01, 2014 at 04:45:16PM +0200, Sumedha Widyadharma wrote:
> It is silently dropped, you have to enable CONFIG+=check_examples to
> get a notice about this. Why is that?
>
> Shouldn't it always warn the user?
>
there are some false positives which i found non-trivial to avoid
cleanly, so i opted for the silent default. as the "user" is in this
case the developer, and any non-trivial buildsystem-related changes
should be reviewed by me anyway, this seemed like a sensible choice.
back then. ^^
From oswald.buddenhagen at digia.com Mon Aug 4 12:51:58 2014
From: oswald.buddenhagen at digia.com (Oswald Buddenhagen)
Date: Mon, 4 Aug 2014 11:51:58 +0200
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
References:
<65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
Message-ID: <20140804095158.GC27299@troll08.it.local>
On Fri, Aug 01, 2014 at 02:24:03PM -0400, Jake Petroules wrote:
> What might be good, too, is a QMAKE_EMBEDDED_FRAMEWORKS or somesuch
> which copies the Qt frameworks into the application bundle at build
> time (though you'd still set DYLD_LIBRARY_PATH because not everyone
> would necessarily use QMAKE_EMBEDDED_FRAMEWORKS). No reason to
> postpone that step to macdeployqt; this is how the native Apple tools
> work anyways.
> Ossi will disagree with me here and say that anything to do with
> creating bundle structures is a deployment step only, though. :)
>
of course, but that has no bearing to qmake, as it does in-place
deployment anyway (cf. QMAKE_BUNDLE_FILES. which means that your
variable would be called QMAKE_BUNDLE_FRAMEWORKS, and would actually
just be a convenience wrapper around the former). also, qmake has a
deploy step: "install". but as-is, it is mostly meaningless for bundle
builds.
also, in some other thread (or a jira task or review) i stipulated that
*deployqt should be backends of qmake anyway, fully controlled by
variables defined within the project (and the make invocation). that
would make the question where the step belongs meaningless.
and as you know, in the qbs context i insist that dependencies must be
declared exclusively via the Depends item (and not ever any compiler and
linker flags), for which one of the reasons is allowing the tool to make
sensible deployment decisions depending on the target and build type.
From oswald.buddenhagen at digia.com Mon Aug 4 12:51:58 2014
From: oswald.buddenhagen at digia.com (Oswald Buddenhagen)
Date: Mon, 4 Aug 2014 11:51:58 +0200
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
References:
<65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
Message-ID: <20140804095158.GC27299@troll08.it.local>
On Fri, Aug 01, 2014 at 02:24:03PM -0400, Jake Petroules wrote:
> What might be good, too, is a QMAKE_EMBEDDED_FRAMEWORKS or somesuch
> which copies the Qt frameworks into the application bundle at build
> time (though you'd still set DYLD_LIBRARY_PATH because not everyone
> would necessarily use QMAKE_EMBEDDED_FRAMEWORKS). No reason to
> postpone that step to macdeployqt; this is how the native Apple tools
> work anyways.
> Ossi will disagree with me here and say that anything to do with
> creating bundle structures is a deployment step only, though. :)
>
of course, but that has no bearing to qmake, as it does in-place
deployment anyway (cf. QMAKE_BUNDLE_FILES. which means that your
variable would be called QMAKE_BUNDLE_FRAMEWORKS, and would actually
just be a convenience wrapper around the former). also, qmake has a
deploy step: "install". but as-is, it is mostly meaningless for bundle
builds.
also, in some other thread (or a jira task or review) i stipulated that
*deployqt should be backends of qmake anyway, fully controlled by
variables defined within the project (and the make invocation). that
would make the question where the step belongs meaningless.
and as you know, in the qbs context i insist that dependencies must be
declared exclusively via the Depends item (and not ever any compiler and
linker flags), for which one of the reasons is allowing the tool to make
sensible deployment decisions depending on the target and build type.
From ono at java.pl Mon Aug 4 13:22:01 2014
From: ono at java.pl (Adam Strzelecki)
Date: Mon, 4 Aug 2014 12:22:01 +0200
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To:
References: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
<53DBF1F5.7030401@tungware.se>
<4BF629EA-C68A-434B-A042-27EA671D92FF@petroules.com>
<4A3F9CEC-5459-4F42-9426-875D0D8B7E69@petroules.com>
<739BD054-A176-4991-8928-CED4493BF0F4@java.pl>
Message-ID:
> So, let's end this discussion and start focusing efforts towards building the solution.
I have wrote that your suggestions should be implemented without any doubt, but whether copy on build should be default it is really a matter of preference, that's why this has to be config option which may be default or not, I don't care, I don't want to argue about that. All I care it to have a choice.
Luckily Qt project isn't done completely Apple way where you have absolutely no choice and there are only one valid solution.
Now let's focus on submitting patches :>
Cheers,
--
Adam
From ono at java.pl Mon Aug 4 13:22:01 2014
From: ono at java.pl (Adam Strzelecki)
Date: Mon, 4 Aug 2014 12:22:01 +0200
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To:
References: <65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
<53DBF1F5.7030401@tungware.se>
<4BF629EA-C68A-434B-A042-27EA671D92FF@petroules.com>
<4A3F9CEC-5459-4F42-9426-875D0D8B7E69@petroules.com>
<739BD054-A176-4991-8928-CED4493BF0F4@java.pl>
Message-ID:
> So, let's end this discussion and start focusing efforts towards building the solution.
I have wrote that your suggestions should be implemented without any doubt, but whether copy on build should be default it is really a matter of preference, that's why this has to be config option which may be default or not, I don't care, I don't want to argue about that. All I care it to have a choice.
Luckily Qt project isn't done completely Apple way where you have absolutely no choice and there are only one valid solution.
Now let's focus on submitting patches :>
Cheers,
--
Adam
From jedrzej.nowacki at digia.com Mon Aug 4 14:03:55 2014
From: jedrzej.nowacki at digia.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki)
Date: Mon, 4 Aug 2014 13:03:55 +0200
Subject: [Development] Problem compiling qtcreator on armhf
In-Reply-To: <127928028.WGqQBLDp7e@luna>
References: <5061774.6mFCvuzPVv@luna> <127928028.WGqQBLDp7e@luna>
Message-ID: <2427821.lvkZjTfpX9@42>
On Saturday 02 of August 2014 14:53:10 Lisandro Damián Nicanor Pérez Meyer
wrote:
> Just for the record, I'm also seeing this while compiling:
>
> /home/lisandro/qtcreator/src/plugins/qmldesigner/designercore/model/qmltextg
> enerator.cpp: In member function 'QString
> QmlDesigner::Internal::QmlTextGenerator::toQml(const
> QmlDesigner::AbstractProperty&, int) const':
> /home/lisandro/qtcreator/src/plugins/qmldesigner/designercore/model/qmltextg
> enerator.cpp:130:13: warning: case value '38' not in enumerated type
> 'QVariant::Type' [-Wswitch] case
> static_cast(QMetaType::Float):
Fixed by e013c7e6.
Cheers,
Jędrek
From jedrzej.nowacki at digia.com Mon Aug 4 14:03:55 2014
From: jedrzej.nowacki at digia.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki)
Date: Mon, 4 Aug 2014 13:03:55 +0200
Subject: [Development] Problem compiling qtcreator on armhf
In-Reply-To: <127928028.WGqQBLDp7e@luna>
References: <5061774.6mFCvuzPVv@luna> <127928028.WGqQBLDp7e@luna>
Message-ID: <2427821.lvkZjTfpX9@42>
On Saturday 02 of August 2014 14:53:10 Lisandro Damián Nicanor Pérez Meyer
wrote:
> Just for the record, I'm also seeing this while compiling:
>
> /home/lisandro/qtcreator/src/plugins/qmldesigner/designercore/model/qmltextg
> enerator.cpp: In member function 'QString
> QmlDesigner::Internal::QmlTextGenerator::toQml(const
> QmlDesigner::AbstractProperty&, int) const':
> /home/lisandro/qtcreator/src/plugins/qmldesigner/designercore/model/qmltextg
> enerator.cpp:130:13: warning: case value '38' not in enumerated type
> 'QVariant::Type' [-Wswitch] case
> static_cast(QMetaType::Float):
Fixed by e013c7e6.
Cheers,
Jędrek
From Morten.Sorvig at digia.com Mon Aug 4 15:27:35 2014
From: Morten.Sorvig at digia.com (Sorvig Morten)
Date: Mon, 4 Aug 2014 12:27:35 +0000
Subject: [Development] Qt 4.x and Qt 5 frameworks should use
@rpath (QTBUG-31814)
In-Reply-To:
References:
<65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
<53DBF1F5.7030401@tungware.se>
<4BF629EA-C68A-434B-A042-27EA671D92FF@petroules.com>
<4A3F9CEC-5459-4F42-9426-875D0D8B7E69@petroules.com>
<739BD054-A176-4991-8928-CED4493BF0F4@java.pl>
Message-ID: <1FBDE5E8-CC2E-46AD-9132-E200389671BD@digia.com>
On 04 Aug 2014, at 12:22, Adam Strzelecki wrote:
>> So, let's end this discussion and start focusing efforts towards building the solution.
>
>
> Now let's focus on submitting patches :>
Before you do that, can you write up a proposal on what you want to accomplish and how to get there? There are multiple stake-holders (including me) who do not necessarily want to read through an email discussion and/or patches in order to see the big picture.
I agree we should make Qt relocatable (with @rpath). I also think the current macdeployqt solution works adequately. There is one standing issue: code signing does not work on 10.9+. I would like to see this resolved before work on using @rpath begins.
(I don’t work on the installer framework so I don’t have an opinion there.)
Morten
From thiago.macieira at intel.com Mon Aug 4 15:27:15 2014
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 04 Aug 2014 09:27:15 -0300
Subject: [Development] [docs/c++] How do we deal with the special member
functions (copy/move ctor/assignment operator, dtor, default ctor)
In-Reply-To: <201408040931.12074.marc.mutz@kdab.com>
References: <201408012316.40275.marc.mutz@kdab.com>
<201408040931.12074.marc.mutz@kdab.com>
Message-ID: <2457417.0IpRFx3QOc@tjmaciei-mobl4>
On Monday 04 August 2014 09:31:12 Marc Mutz wrote:
> On Monday 04 August 2014 08:02:51 Knoll Lars wrote:
> > On 02/08/14 18:21, "Thiago Macieira" wrote:
> > >Why do we have to document them in the first place? I hate having to
> > >write
> > >documentation for a destructor that simply says "frees resources
> > >associated
> > >with this object".
> Ok, fair enough, but how, then, is a user-defined special member function
> (where user = Qt developers) different, assuming, of course, that the user-
> defined copy ctor actually copies...? It's an implementation detail whether
> the implicit version works or whether a user implementation is necessary..
> By documenting one and not the other, we either leak that information, or
> make new C++ users think that some classes - that are - aren't copyable.
As I said, I'd rather not document any of them if they don't do anything
special and don't have user-visible impacts. The fact that we had to document
a few notwithstanding: we should modify qdoc so there's a way to document a
type as copyable and also suppress those special constructors in the docs.
> Worse: unless you look at the header file, there's no way to predict whether
> the implicitly declared, say, copy constructor is deleted or defaulted. And
> it's not as if Q_DISABLE_COPY generates any documentation.
The solution is to make Q_DISABLE_COPY generate documentation and mark the
type as non-copyable.
> So maybe the real questions is, as Thiago said, how to document whether a
> class is a value class or polymorphic (though, of course, there are more
> than these two: move-only classes, RAII classes (with some overlap between
> the two, etc)).
>
> \valueclass
> \polymorphic
> \raii
> \move-only
>
> Or just
>
> \implicitdefaultctor
> \impicitcopyctor
> \implicitmovector
> \implicitdtor
> \implicitcopyassignment \____> \implicitassignment
> \implicitmoveassignment /
I'd rather have \valueclass and Q_DISABLE_COPY. The in-between cases will
require per-method documentation.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
From thiago.macieira at intel.com Mon Aug 4 15:22:50 2014
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 04 Aug 2014 09:22:50 -0300
Subject: [Development] Qt 4.x and Qt 5 frameworks should use @rpath
(QTBUG-31814)
In-Reply-To:
References:
Message-ID: <1913544.ospdoc7Pqu@tjmaciei-mobl4>
On Monday 04 August 2014 12:22:01 Adam Strzelecki wrote:
> I have wrote that your suggestions should be implemented without any doubt,
> but whether copy on build should be default it is really a matter of
> preference, that's why this has to be config option which may be default or
> not, I don't care, I don't want to argue about that. All I care it to have
> a choice.
Let's put it this way:
- qmake should not generate code that copies on make
- macdeployqt should do that copying
Qt Creator can choose between running macdeployqt or setting DYLD_xxx_PATH. My
suggestion is to run macdeployqt for bundle applications since they may be
attempting to use resources inside their bundles.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
From thiago.macieira at intel.com Mon Aug 4 15:19:11 2014
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 04 Aug 2014 09:19:11 -0300
Subject: [Development] Relative paths in EXAMPLE_FILES in .pro files
In-Reply-To: <53DF2ED5.4060700@basyskom.com>
References: <53DBA7FC.5070600@basyskom.com>
<36078478.Agox8kLvH2@tjmaciei-mobl4>
<53DF2ED5.4060700@basyskom.com>
Message-ID: <3229068.UhcUGOVNUp@tjmaciei-mobl4>
On Monday 04 August 2014 08:57:25 Sumedha Widyadharma wrote:
> See: mkspecs/features/qt_example_installs.prf
>
> > You can assign any value to any variable you want in qmake. Whether you
> > make use of the variable or not, it's up to you.
>
> This variable is used internally.
You mean "externally". You've found the .prf file that does the checking, so
it's not qmake.
Anyway, looks like you've found the reasons all on your own.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
From Morten.Sorvig at digia.com Mon Aug 4 15:27:35 2014
From: Morten.Sorvig at digia.com (Sorvig Morten)
Date: Mon, 4 Aug 2014 12:27:35 +0000
Subject: [Development] Qt 4.x and Qt 5 frameworks should use
@rpath (QTBUG-31814)
In-Reply-To:
References:
<65816448-AFE9-45D9-93E4-2326D33A2B85@petroules.com>
<53DBF1F5.7030401@tungware.se>
<4BF629EA-C68A-434B-A042-27EA671D92FF@petroules.com>
<4A3F9CEC-5459-4F42-9426-875D0D8B7E69@petroules.com>
<739BD054-A176-4991-8928-CED4493BF0F4@java.pl>