On 2014-08-09, at 04:33 PM, Thiago Macieira <thiago.macie...@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@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at petroules.com Chief Technology Officer - Petroules Corporation _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development