> It looks like we have to leave this to to the deployment solution
> (macdeployqt does not deploy the file).
I understand, however then we get frameworks that cannot be code-signed if
copied just straight from the folder just because this single .prl file.
Can you please share some details why
Just want to humbly remind that we still need to get rid of .prl files from Qt
module frameworks roots. Either move the one level up or into Resources/
--Adam
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/li
> qmake - framework bundle hierarchy (QTBUG-32895):
> https://codereview.qt-project.org/95454
> qmake - “_debug" in CFBundleExecutable (QTBUG-32894):
> https://codereview.qt-project.org/95455
> qmake - add CFBundleVersion: https://codereview.qt-project.org/95456
> macdeployqt - “Current” version
> As far as I'm aware, we already do this correctly (aside from Info.plist
> being in the wrong place), and the only reason _debug is showing up in an
> Info.plist somewhere is probably due to some simple typo or omission.
You're right, thanks.
--Adam
___
> codesigning complaining on this _debug reference
> CFBundleExecutable
> QtPrintSupport_debug
Shouldn't be debug another version within multiversioned bundle? E.g.:
QtCore -> Versions/Current/QtCore
Resources -> Versions/Current/Resources
Versions/
> Reported already 24/Jan/14 QTBUG-36429
FYI more recent and prioritized bug report is QTBUG-38511
I think it deserves a lot of attention now since 10.9.5 is live.
--Adam
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.o
Thanks a lot for pointing me to the bug report and original thread. Somehow it
has hit me today once I've upgraded to 10.9.5 that brings stricter signing
policy.
--Adam
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org
Briefly - current Qt5 frameworks bundles structure is invalid & cannot be code
signed anymore in 10.9.5 & 10.10. Also
Please have a look at Apple's recent TN2206:
https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG205
And refe
> Discussed on IRC with Jake
I completely missed the fact there's an IRC channel. How there as "OnO". Fell
free to ping me.
--Adam
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
> Afaics the suggestion is to never have the absolute path to the Qt frameworks
> added to the rpath at all. Which would make the rpaths *only* be useful for
> the bundled dependencies. So, when not using the “bundle stuff” option, it
> would require setting either DYLD_ in the run environme
Oswald Buddenhagen wrote:
> yes. except that i want these to be called QMAKE_BUNDLE_*.
> this is irrespective of x-platform use. i like the idea of calling the
> functionality "bundling".
Yup, that sounds better. So they will be:
QMAKE_BUNDLE_LIBRARIES
QMAKE_BUNDLE_PLUGINS
Ziller Eike wrote:
> Can we please already now turn a cross-platform hat on, and at least think
> about options that at least do not right away block using the same for non-OS
> X?
Sure, this is just a proposition, "bundle_qt" (proposed in latter posts) seems
to match it better.
> I do not se
> Err, what? Standard use case is @rpath + copy frameworks. So if that's done
> by default, and macdeployqt is deleted, no one is bothered.
But app won't start, because it needs to resolve Qt libs referenced via @rpath
to @executable_path/../Frameworks, thus accompanying `QMAKE_RPATHDIR =
@exec
> Please stop saying that to fuel your argument just because I disagree with
> some of your points; it sounds kind of rude. Also, I am one of these
> "stakeholders", though I'm not sure what definition you're going off of,
> because the dictionary's definition "a person with an interest or conce
> The target name: Should that be “deploy”? “make deploy" would then perform
> platform-specific deployment.
Well, I think "deploy" isn't a correct name. IMHO deployment is more like
uploading application (service) to target system. We aren't to upload or
transfer anything.
So either "bundle"
Okay, Phase II.
(1) Introduce "bundle_frameworks" CONFIG option, and set it default for "rpath"
shared builds on iOS & OS X
(2) Introduce "bundle" make target, when "bundle_frameworks" CONFIG is set, it
is added to "all"
(3) Make's "bundle" will copy (update if not there) all used Qt framework
> On to my now standard question: Can you summarize the discussion so far into
> a proposal on what you want to change? Keep it as short as possible :) For
> example, I think it’s understood that (incremental) framework coping is fast
> - no need to go into details. On the other hand I think it’
> How does a launched application find the Qt frameworks that were installed by
> the SDK? And how do those frameworks find the plugins?
"Phase I" changes does not change workflow, so all apps built with Qt find Qt
libraries as before. Since all Qt libraries are now using @rpath id prefix they
The changes for qtbase are there:
https://codereview.qt-project.org/91669
https://codereview.qt-project.org/91670
https://codereview.qt-project.org/91671
https://codereview.qt-project.org/91672
https://codereview.qt-project.org/91673
https://coderevi
> So I think at this point we can agree on this so far, on the condition that:
>
> (1) The remaining absolute rpath will not be a permanent thing and is simply
> postponed to "Phase II"
Yes, but please note that "Phase I" doesn't make changes to existing workflow,
while "Phase II" will. So Qt s
Then we can
discuss further workflow improvements.
Regards,
--
Adam Strzelecki
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
> 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
> 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
> 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
> 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 her
> 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
>> 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 a
There is long standing bug report from back 2011 (Qt 4.7.4) that still applies
to recent Qt version and Qt Creator:
"Broken Layout on Mac"
https://bugreports.qt-project.org/browse/QTBUG-23042
This is nothing that has impact on performance or stability, but it just makes
Qt Creat
> Qbs has by definition more features than cmake because it is a make tool.
I understand Qbs may have greater potential by design, but it has far less
features than CMake today. I refer features as ability to detect various
components, such as CUDA, OpenGL and support many platforms. However I d
Putting my 2¢ in, Qmake is IMHO good enough. Qbs is kind of vaporware, sparse
documentation, needs Qmake to build (woot?!).
Altogether it sounds like a clinch, we don't want to extent Qmake with ninja or
anything, because there comes Qbs. But Qbs isn't really there, because one
needs lot of wor
> I would recommend using CMake - it has a stable Ninja generator, which
> _does_ make building Qt projects much faster on Windows.
I wonder if can CMake build Qt SDK itself?
It is somehow parallel to Qmake, isn't it. If so, would it make sense to make
Qt to depreciate Qmake at some point in fav
Hello,
I wonder if there was any work done in regards of making Ninja Qmake generator.
From my experience Ninja vastly improves (re)build time. I wonder if it would
be hard to make such generator, or if anyone tried to do it already.
Cheers,
--
Adam
for it
> in the code
> that uses Qt 4.8.
>
> Thanks, Kuba
>
> On Mar 18, 2014, at 6:25 AM, Adam Strzelecki wrote:
>
>> Hi,
>>
>> I there any chance to backport object_parallel_to_source to 4.8.6 as
>> reported here:
>>
>> https://bugrep
> well, what is more important? adding new features or fixing existing
> bugs? for one of my use case, there were quite a number of showstopper
> bugs in qt-5.2 so i'm glad that 5.3 focused more on stability than on
> features …
I wish it was like that but still I can find some outstanding bugs th
Hi,
I there any chance to backport object_parallel_to_source to 4.8.6 as reported
here:
https://bugreports.qt-project.org/browse/QTBUG-34871
This is really tiny change:
https://qt.gitorious.org/qt/qtbase/commit/47df12225918ba82abe35921af19e547717da58b?format=patch
Best regards,
--
Adam
_
> Qt 5.2.1 release is coming soon. Here is a link to the known issues page.
> Please add needed issues there.
I guess this one could be worth mentioning for Mac, unless fix makes it way
into 5.2.1
https://bugreports.qt-project.org/browse/QTBUG-36373
"OSX Retina low resolution w
> I'm guessing it has something with the unified title and toolbar on mac fix?
I’d also loot at that direction, however I just can’t believe such a fix may
remove 60MB of the library code :>
--
Adam
___
Development mailing list
Development@qt-project.
I have just noticed that OSX 5.2.1 offline snapshot (clang) DMG is 60MB slimmer
(396 MB) than it was in 5.2.0 (455 MB). Do you know what is the reason of such
difference?
Regards,
--
Adam
___
Development mailing list
Development@qt-project.org
http://
> Good ideas are welcome
>
(1) If you want it system wide, we could use well-known path relative to the
.app, either SDKs inside the .app itself, or „Qt" folder next to "Qt
Creator.app", I don’t know which one is better, but I believe /Applications
folder is best place because it easy to figure
> There are other installers though, either from Digia, or other companies
> (enterprise Qt packages, SailfishOS SDK, …) which have other requirements.
> Meaning that we need to have some kind of Qt installers for Mac anyhow.
Agreed. If you have dedicated machine for dedicated tools that works b
> So that would always contain the Qt sources, documentation and examples too?
Yes, Kai wrote he sees no point to be able to not install docs & examples
together with SDK as suggested in QTBUG-34870. So once Qt Creator isn’t there,
bundled frameworks use @rpath, is there any point to have an ins
Jake Petroules wrote:
> But what exactly do you include in the offline installer?
Thanks for detailed insight. I think I am all way with /Applications/Qt
Creator.app/Contents/SDKs/{mkspec}-{version}.qtsdk/ because of simple reason
that on OSX you don’t need elevated permissions to put anything i
> Yeah. Unfortunately it's not that easy to fix, since the Qt versions /
> toolchains packages register themselves into Qt Creator.
Does it have to be so complicated? Why QtCreator just not figures out installed
Qt versions upon next run if they are installed on well known location,
otherwise j
FYI, installer font is still messed up on OSX 10.9. I have tried to find the
original bug report but only found QT 4.8.x reports marked fixed:
https://bugreports.qt-project.org/browse/QTBUG-33049
https://bugreports.qt-project.org/browse/QTBUG-32789
https://bugreports.qt-project.org/browse/QTBUG-31
I am sorry, it was thinking of backporting object_parallel_to_source :>
Regards,
--
Adam
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Hello,
Also I am curious why object_with_source was never backported to Qt 4.8.x. It
exists in Qt5 branch since least few last Qt 4.8 minor releases and it brings
significant improvement separating build folder from source tree.
Would it be possible to port it back? AFAIK looking in Qmake code
46 matches
Mail list logo
