[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