The problem is also, that it causes inconsistencies under Windows, i.e. there are now some cases where the case of the letters matter and some others where it doesn't matter at all. We've discussed the paths in the QtCreator, so they distinct between Upper and lower letters. But for example it is possible to import libraries in .pro files without taking care of Upper and lower cases (LIBS += <PATH> -lLibrary with windows is the same as LIBS += <Path> -llibrary), such that this .pro file may not be unix compatible. So whatever solution may be chosen for this matter (case sensivity with windows) in my opinion it should at least be consistent within Qt and its qmake system.
Greetings Matthias -----Original Message----- From: Koehne Kai [mailto:kai.koe...@digia.com] Sent: Donnerstag, 25. Oktober 2012 12:36 To: Chris Adams Cc: Wehmer, Matthias; development@qt-project.org Subject: RE: [Development] QmlImportPath > -----Original Message----- > From: Chris Adams [mailto:chris.ad...@qinetic.com.au] > Sent: Thursday, October 25, 2012 2:23 AM > To: Koehne Kai > Cc: Wehmer, Matthias; development@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 ... --- This communication contains confidential information. If you are not the intended recipient please return this email to the sender and delete it from your records. Diese Nachricht enthaelt vertrauliche Informationen. Sollten Sie nicht der beabsichtigte Empfaenger dieser E-mail sein, senden Sie bitte diese an den Absender zurueck und loeschen Sie die E-mail aus Ihrem System. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
