[Development] Qt 4.x and Qt 5 frameworks should use @rpath (QTBUG-31814)
Jake Petroules
jake.petroules at petroules.com
Sat Aug 9 22:54:58 CEST 2014
On 2014-08-09, at 04:33 PM, Thiago Macieira <thiago.macieira at intel.com> wrote:
> On Saturday 09 August 2014 15:56:57 Jake Petroules wrote:
>>> Not to mention that qmake has no QCoreApplication in the first place.
>>
>> It's a static method.
>
> I meant that the qcoreapplication.cpp file isn't compiled for qmake.
In any case, a minor concern.
>>> That leaves out very important to us: Android and QNX. They fall back to
>>> parsing argv[0], which can fail for a variety of reasons, including users
>>> passing dummy argv arrays to QCoreApplication.
>>
>> Excluding Android and QNX, can we leave each path in qmake empty unless
>> otherwise specified, in order to allow it to fall back to a default based
>> on the filesystem location of qmake[.exe]? CONFIG could contain a new
>> dynamic_qmake_path; mkspecs for platforms other than Android and QNX can
>> add this. When building qmake, add:
>>
>> 1. User-specified path from configure (cut off the prefix if the platform
>> has dynamic_qmake_path, too), or:
>> 2. Default path based on prefix specified in configure if !
>> dynamic_qmake_path, or:
>> 3. Empty string, in which case applicationFilePath + XXX is used at runtime
>>
>> Would this work?
>
> I'd rather just keep relative paths and let qmake discover the prefix from its
> own path.
Yes, that's essentially what I'm suggesting. There'd just be no *absolute* hardcoded paths...
> --
> 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
--
Jake Petroules - jake.petroules at petroules.com
Chief Technology Officer - Petroules Corporation
More information about the Development
mailing list