Stefan Teleman wrote:
>
>
> Darren J Moffat wrote:
>> Does it really make sense to have all of QT hidden away in /usr/qt4 ?
>> I was expecting at least some things like include files or libraries
>> to be under /usr/include and /usr/lib respectively.
>>
>> My concern is how are autoconf, and the like, scripts that need to
>> find QT libraries and includes going to find it ? Are we expecting
>> that everyone will know to do something like this:
>>
>> ./configure --with-qt-include=/usr/qt4/4.4.1/include \
>> --with-qt-libs=/usr/qt4/4.4.1/lib/
>>
>> Is there no pkg-config .pc file for QT that can be placed in
>> /usr/lib/pkgconfig to help with this ?
>
> PKG_CONFIG_PATH can be set to
> /usr/qt4/4.4.1/lib/pkgconfig:${PKG_CONFIG_PATH}.
That assumes I already now where it is hidden, which kind of defeats the
part of point of pkgconfig
The pkg-config file should be in /usr/lib/pkgconfig we already set
precedence for this in other cases. I have no problem with providing
multiple pkgconfig files under the path you gave but the canonical
version of qt should have one in /usr/lib/pkgconfig
> Or, one can say --with-qt-include=${QTDIR}/include
> --with-qt-libs=${QTDIR}/lib
$QTDIR isn't defined in my environment.
>> Is this the common layout on Linux based distributions where GNOME is
>> considered the primary desktop rather than KDE ? What is they layout
>> when KDE is the primary desktop ?
>
> SUSE organizes as /usr/lib/qt3 /usr/lib/qt4, etc
where are the include files on SUSE ?
Why is your layout better than the SUSE one ? What problems does it
solve that their layout doesn't ?
> The question is: what happens when we want to include a newer version of
> QT (QT 4.5.0 is already out), which comes with newer and likeable
> features ? The two versions have to be able to coexist someohow, without
> creating conflicts.
That layout is okay for that but please provide the pkgconfig .pc file
in a place that is found by default for the recommended version
(currently 4.4.1).
>>> This Fasttrack proposes an overall "Uncommitted" Interface
>>> Stability Classification for QT4. Considering the ABI Micro
>>> Release Stability guarantee provided by Trolltech ASA, a
>>> "Committed" Interface Stability Classification would have been
>>> appropriate. However, QT4's dependency on
>>> External/Evolving/Uncommitted Interfaces makes an overall
>>> "Committed" Interface Classification inaproppriate.
>>
>> That doesn't follow. Just because you have lower classified
>> dependencies doesn't mean you can't be higher than them. That is the
>> definition of what we do in ARC. Everything is built on something of
>> a lower classification at some level. So if this really could be
>> Committed other than for the incorrect assumption on the dependencies
>> it should be Committed.
>
> It can't be Committed because [1] it doesn't really implement any known
> Industry standard,
That isn't the definition of committed.
> and [2] we don't control QT's Interface Stability level.
Then what was all that text above about ? It can be Committed if the
project team believes that the upstream behaves in a manner suitable.
The text you provided indicates you do think that.
--
Darren J Moffat
