[blfs-dev] [blfs-book] r11616 - trunk/BOOK/x/lib
krejzi at email.com
Sun Aug 11 15:27:42 PDT 2013
On 11.8.2013 23:56, Bruce Dubbs wrote:
> Armin K. wrote:
>> On 11.8.2013 23:24, bdubbs at higgs.linuxfromscratch.org wrote:
>>> Author: bdubbs
>>> Date: Sun Aug 11 14:24:18 2013
>>> New Revision: 11616
>>> Add alternate Qt5 build instructions
>> I still have no idea why you added these instructions when you still
>> symlink the binaries into /usr/bin. I find it pointless. Since yet
>> nothing uses Qt5 (no desktop and such), it can be easily overwriten
>> without any problems in /usr.
> Planing for the future. I thought about mentioning changing the PATH,
> but decided the user could figure that out.
That has several disadvantages currently (the path thing) since most
apps looking for qmake in path will look for qt version 4.
>> Also, qtchooser won't work for this one.
> Really? I figured that the only thing needed would be to
> cat > /etc/xdg/qtchooser/5.conf << "EOF"
> That said, I've never liked the 'alternative' scripts. It's easier to
> just change the PATH.
For this, it's enough to set/unset an env var.
> I've also thought about making the path functions in /etc/profile
> persistent. Then the qtchooser would be simply
> pathremove old-qt-path; pathprepend new-qt-path
> pathprepend alternate-qt-path
> do build
> pathremove alternate-qt-path
> Another option would be to just change the /opt/qt symlink, but that
> requires being root.
> -- Bruce
And ton of another workarounds, variables and configure/cmake switches
we don't know yet. More or less, it should be always safe to update the
package even if it's in /usr since well, such package shouldn't be
updated if you are running from the Qt5 terminal. (same applies for
GTK+, Xorg, etc). The trick is, nothing can be updated (by just issuing
make install and letting the process overwrite everything) without
More information about the blfs-dev