On 21 Sep 2012, at 6:01 PM, ext Thiago Macieira wrote:

>       pkgconfig/ - versioned .pc files
>       qt5/             - arch-specific support files:
>               bin/ or libexec/
>                - executables not run by the user, like syncqt, lrelease, 
> lupdate
>               imports/
>                - QtDeclarative imports
>               qml2/
>                - QML2 (including QtQuick2) arch-specific imports
>               mkspecs/ ?
> share/        - arch-independent files
>       qml2/    - QML2 (including QtQuick2) arch-independent imports
>       qt5/
>               doc/
>               examples/
>               mkspecs/        ?
> 
> Note on imports: the design is flawed. It was flawed in Qt 4 and it's worse 
> now 
> on Qt 5. For Qt 4, the flaw was that it did not differentiate QML imports 
> that 
> were arch-independent from the ones that required plugins. With Qt 5, it 
> becomes worse because Qt Quick 1 and 2 share the same directory.
> 
> Instead, I recommend we immediately change QML2 to the system that Perl uses: 
> put the arch-specific files inside the lib hierarchy, for which distributions 
> have already solved the multiarch problem, but put arch-independent files in 
> the share hierarchy.

That makes sense.  But having both lib/qt5/imports and lib/qt5/qml2 is 
confusing.

There's no problem to mix up .so and .qml files inside a "package" 
(Qt/labs/foopkg or MyCompany/mypackage), right?  The qmldir just has to list 
all the files.  (Which is conceptually redundant, but that's another topic.)

Or is the point just to separate QtQuick 1 and 2?  Why not rename imports to 
qml1 then?  Or call them quick1 and quick2 because it's a place to put Qt Quick 
packages, not just qml files.

_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to