[Development] QmlImportPath
Koehne Kai
Kai.Koehne at digia.com
Thu Oct 25 12:36:14 CEST 2012
> -----Original Message-----
> From: Chris Adams [mailto:chris.adams at qinetic.com.au]
> Sent: Thursday, October 25, 2012 2:23 AM
> To: Koehne Kai
> Cc: Wehmer, Matthias; development at qt-project.org
> Subject: Re: [Development] QmlImportPath
>
> [...]
> I believe that the problem is that (as Aaron states in that change request) if
> we don't enforce case-sensitivity, we get the unfortunate situation that an
> application which works on Windows, or Mac OS X, might not work on Linux.
> By enforcing case sensitivity, we ensure that the application works on all
> platforms without requiring any changes. In the past, we had heaps of bug
> reports about this exact issue, until we started enforcing case sensitivity on
> all platforms.
Hi,
I understand the reasoning, but there's pain on the other side too: As soon as you integrate QML like Qt Creator does, you're likely hit by problems. Just look at the list of linked bugs in Qt Creator under
https://bugreports.qt-project.org/browse/QTBUG-17529
Absolute paths that work for the rest of Qt break for QML ... The counter measure is 'normalizing' paths handed over to QtDeclarative/QtQml, but there's not even a Qt API for it. Now you could argue that Qt Creator is somehow special, but Matthias isn't the first external one complaining about this, there have been others before too ...
So all in all, I think the current strict checking does more harm than good. Alternatives I see are:
- normalizing paths handed over via public API (this is what my patch does)
- change error into a warning
- just check for file names, not directories
- get rid of the check altogether, and maybe warn about potential problems in the Qt Creator IDE
> I've added Martin Jones to that change request to get his opinion, but I
> would be surprised if changing this behaviour at this point in time is
> sensible.
>
> Cheers,
> Chris.
PS: Is there any other interpreter / compiler being so strict about file casing like we are? I don't think I've encountered one ...
More information about the Development
mailing list