Re: [Development] New proposal for the tool naming
On 10/20/2012 02:16 AM, Thiago Macieira wrote: [...] 3) In addition, we'll create a *new* tool also called qmake that will be installed to $bindir. This tool shall have the following behaviours: a) under most circumstances, it will simply find another qmake and pass through all arguments. That is: qmake -project basically will exec $someotherpath/qmake -project b) additionally, it accepts an extra argument (-select), which causes it to select a different Qt version. For example: qmake -qt=5 -project qmake -qt=4.8.4 CONFIG+=debug etc. [...] As you seem to hint in the follow-up e-mail, this is not limited to version numbers, but can contain toolchain information: qmake -qt=5 qmake -qt=5-mingw32 qmake -qt=4.8-maemo5 Right? If so, that would be excellent. [...] Additionally, this tool may support options like -add-qt and -set-default-qt. I'm also open to adding an option -run-tool= (e.g., qmake -qt=5 -run- tool=qmlplugindump) if that's of interest to people. If you are open to feature requests, here's another one: -store (or any better name) which stores the value of the -qt= option into $PWD/.qmake-config which the qmake wrapper will use as default configuration when run from this directory with no -qt argument. That would allow one to do: cd ~/src/projectA qmake -qt=5 -store [...] cd ../projectB qmake -qt=5-mingw32 -store And from that time on one doesn't need to remember what qt version or toolchain one has to use for a project, and just always type qmake from the project base directory. Ciao, Alberto -- http://blog.mardy.it - geek in un lingua international! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
On sábado, 20 de outubro de 2012 09.53.24, Alberto Mardegan wrote:
As you mentioned in another message, it would be great if these paths
were discoverable, either with a qt5-config tool or (better, IMHO) with
a qt5.pc pkg-config file defining these variables, so that one could do:
$ pkg-config --variable=QT_INSTALL_BINS qt5
/usr/lib/qt5/bin
They're in Qt5Core.pc already:
$ cat lib/pkgconfig/Qt5Core.pc
prefix=/home/thiago/obj/qt/qt5/qtbase
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include/QtCore
qt_config=lex yacc warn_on debug exceptions depend_includepath wayland-scanner
qt warn_on link_prl incremental gdb_dwarf_index qpa no_mocdepend debug
qt_no_framework linux unix posix gcc qpa largefile precompile_header sse2 sse3
ssse3 sse4_1 sse4_2 avx avx2 pcre create_prl link_prl use_libmysqlclient_r
no_private_qt_headers_warning QTDIR_build exceptions shared qt_install_module
qt_install_headers qt warn_on depend_includepath qmake_cache target_qt
qt_install_module_docs create_cmake hide_symbols bsymbolic_functions c++11
create_pc create_libtool explicitlib have_target thread dll shared
moc_location=${prefix}/bin/moc5
rcc_location=${prefix}/bin/rcc5
lupdate_location=${prefix}/bin/lupdate
lrelease_location=${prefix}/bin/lrelease
Name: Qt5core
Description: Qt Core module
Version: 5.0.0
Libs: -L${libdir} -lQt5Core
Libs.private: -lpthread -lz -licui18n -licuuc -lm -ldl -pthread -lgthread-2.0
-lrt -lglib-2.0
Cflags: -I/home/thiago/obj/qt/qt5/qtbase/include -I${includedir}
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On 10/20/2012 11:28 AM, Stephen Kelly wrote: And from that time on one doesn't need to remember what qt version or toolchain one has to use for a project, and just always type qmake from the project base directory. This is the right goal imo, but the wrong implementation. I'm not sure that we have the same goal -- or at least, I didn't understand from your explanation how to achieve it. What I want to be able to do is: # some steps to configure the projects as desired, # and from that time on be able to do $ cd src/projectA $ qmake # uses qmake for qt5 $ cd ../projectB $ qmake # uses qmake for qt4 Without any intermediate steps to select the version (which I might not remember). In order to be able to make this, you need to have a specialized qmake program which decides which qmake binary to run. Ciao, Alberto -- http://blog.mardy.it - geek in un lingua international! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On Saturday, October 20, 2012 12:12:39 Alberto Mardegan wrote: On 10/20/2012 11:28 AM, Stephen Kelly wrote: And from that time on one doesn't need to remember what qt version or toolchain one has to use for a project, and just always type qmake from the project base directory. This is the right goal imo, but the wrong implementation. I'm not sure that we have the same goal -- or at least, I didn't understand from your explanation how to achieve it. What I want to be able to do is: # some steps to configure the projects as desired, # and from that time on be able to do $ cd src/projectA $ qmake # uses qmake for qt5 $ cd ../projectB $ qmake # uses qmake for qt4 Without any intermediate steps to select the version (which I might not remember). In order to be able to make this, you need to have a specialized qmake program which decides which qmake binary to run. Indeed. I missed your goal of the tool figuring out whether to use the Qt 4 or Qt 5 qmake *without* any intermediate steps (presumably you want that stored in $PWD and to apply to all subdirectories when qmake -store is run?). I'm not sure I like that idea, but I guess I could just not use the feature. Regarding remembering, that's also a problem that most people have solved for themselves I'm sure. My shell prompt looks like this: Qt( ) KDE ( ) stephen@hal:~/dev/src$ qt 5 Qt( 5 ) KDE ( ) stephen@hal:~/dev/src$ qt 48 Qt( 4.8 ) KDE ( ) stephen@hal:~/dev/src$ qt 47 Qt( 4.7 ) KDE ( ) stephen@hal:~/dev/src$ qt undef Qt( ) KDE ( ) stephen@hal:~/dev/src$ qt 48 Qt( 4.8 ) KDE ( ) stephen@hal:~/dev/src$ kde 47 Qt( 4.8 ) KDE ( 4.7 ) stephen@hal:~/dev/src$ qt 47 Qt( 4.7 ) KDE ( 4.7 ) stephen@hal:~/dev/src$ So I can't *not* remember. It's right there. Anyway, even if the tool would 'store' the information about which qmake to run, my point about that not being the complete environment still stands. Maybe you can replace 'cd' with a wrapper script? :) Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ** Qt Developer Conference: http://qtconference.kdab.com/ ** signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Status of ActiveQt
Hi all, I'm curious about the status of ActiveQt. The QAxContainer and QAxServer modules seem to still exist in the code base, but aren't listed in http://doc-snapshot.qt-project.org/5.0/modules.html. Is this simply an omission in documentation, or are they being removed? Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of ActiveQt
(Re-including the mailing list) The snapshot is the more recent version of the page you linked. But in any case, I found an old thread ( http://www.mail-archive.com/development@qt-project.org/msg01737.html), which suggests that there's no active maintainer at the moment. Regards, Sze-Howe On Sat, Oct 20, 2012 at 8:19 PM, 1+1=2 he...@debao.me wrote: http://qt-project.org/doc/qt-5.0/modules.html On Sat, Oct 20, 2012 at 7:29 PM, Sze Howe Koh szehowe@gmail.com wrote: Hi all, I'm curious about the status of ActiveQt. The QAxContainer and QAxServer modules seem to still exist in the code base, but aren't listed in http://doc-snapshot.qt-project.org/5.0/modules.html. Is this simply an omission in documentation, or are they being removed? Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure
Wow. I don't usually rubber-neck as I drive by car-crashes, but I must say, this has been one of the more fascinating email chains. Not because of content; but rather, because in my introverted I'm-so-lonely! world, observing humans-being-human has recently become fascinating to me. I had to LMAO when Godwin's law got invoked so fast. Must be a record. My summary (for those that don't want to read further): You're a smart guy, but you're hurting those you're trying to help. Your message is lost because it is so loud, that no one can hear it. I personally would be sorry to see you go, but I understand that such a departure can be a positive healing experience for both you and the Qt community. Since your email announces your departure, I'm responding. I'm not trying to feed-a-troll, and you must admit that you qualify. However, I have specific observations related to the discussion: technical, governance-oriented, and psycho-social. The casual reader will want to stop reading now. On Fri, Oct 19, 2012 at 9:18 PM, d3fault d3faultdot...@gmail.com wrote: On Fri, Oct 19, 2012 at 3:37 PM, Knoll Lars lars.kn...@digia.com wrote: This is just wrong, and I'm getting tired of your ramblings on this mailing list. Just because you send something to the ML and people get tired of answering you doesn't mean your proposal is accepted. I was writing that tongue in cheek and mocking Thiago. Sarcasm You. Ouch. There you're just being mean, as the relational expression does not expand upon your defense/justification. It's really hard to discuss (an implication of an ideas-exchange-back-and-forth) if the sides do not respect each other (there's no point to discussion in that case). That's where we are now. You're frustrated, trying to reverse a lack-of-good-faith (as perceived by at least one side) with further evidence of lack-of-good-faith. My impression of you: You're really smart with significant Qt use-history. I've watched you in many threads on this list, and it's clear you know a lot, and you've made helpful comments/responses on questions including quite technical aspects of Qt internals. I don't agree with you on some project-direction-issues like QWidget/QML, but see the chance for common-ground with some reasonable concessions (e.g., an eventual all-C++-API). However, my summary report would have to be: 15% -- Devil's advocate arguing 30% -- Constructive answers/discussions-to-technical-questions 55% -- Bomb-throwing We have a fully worked out proposal by Rich on the table that many people agreed with, and we'll stick with it for now. His proposal is alright, with the exception of handling incoming vulnerabilities. He didn't even discuss the subject, so what do you even mean sticking with it? Lars, in his role of Chief Maintainer, is trying to conclude a topic after extensive discussion. His job is significant only in those cases where consensus cannot be reached, but a decision is required. This topic appears to warrant that intervention, so Lars is legitimately exercising his duty. Your concession is interesting: His proposal is alright, with the exception of handling incoming vulnerabilities. That was not previously clear to me in the discussion (I may have missed that, there was lots of exciting talk to obscure the point), but this statement is quite clear and constructive. We can focus on the single topic of disagreement (incoming vulnerabilities). ISSUE: Identified vulnerabilities could go to a public-security-list or closed-security-list. PRECEDENT: Significant (large) community (open-governance) projects have done either; examples in this thread include Linux Distros using closed-security-lists, as was tentatively-agreed as the direction within the Qt-community (so that decision can't be crazy-stupid with such precedent). TRADE-OFF: (a) a public-security-list invites script-kiddies to cause mischief without working hard, as exploits are publicly-announced/available before fixes (b) a closed-security-list is a layer requiring mischief-makers to work-a-little-harder to get into the list, and maintain a presence; the benefit is that they may have strategic access to exploits between the announcement-on-the-closed-list and public-disclosure (at which point there would be a fix). COMMUNITY CONCERNS: There's a lot in this section, and this is your main argument. However, I'll put forth a few. (a1) Interruptions/noise is higher with public (v. closed): As an administrator/user, announcement of a security issue without a fix is likely not-actionable, or the shut-my-stuff-down action is a costly over-response. I must await a second announcement, and the first announcement is noise to which I cannot respond, but against which I am now liable (e.g., you've added to my noise, and to my liability, without a benefit). (a2) Risk/exploits are higher with public (v. closed): The script kiddies are invited to cause mischief with publicly-announced
Re: [Development] New proposal for the tool naming
On sábado, 20 de outubro de 2012 10.28.35, Stephen Kelly wrote: On Saturday, October 20, 2012 10:30:36 Alberto Mardegan wrote: On 10/20/2012 02:16 AM, Thiago Macieira wrote: [...] 3) In addition, we'll create a *new* tool also called qmake that will be I wonder how FindQt4.cmake will react to that. If that module finds Qt 5 it is supposed to keep looking for Qt 4. I'm not sure how it would react to qmake suddenly being a perl script instead of qmake.exe for example. The idea is that Linux distributions will make this tool default to Qt 4. So if the user does nothing, FindQt4.cmake will continue working. If the user does something to select Qt 5, that is the user's fault. It's equivalent to setting today's qmake first in $PATH. Why not use a tool of a new name? Why overload the meaning and responsiblity of qmake? Because everyone is complaining of having a new name. As you seem to hint in the follow-up e-mail, this is not limited to version numbers, but can contain toolchain information: qmake -qt=5 qmake -qt=5-mingw32 qmake -qt=4.8-maemo5 Right? If so, that would be excellent. ... but only useful for Qt, not for the whole environment. I have a bash function called qt (and a similar one called kde) which lets me choose an environment where Qt is my focus, but not the limit to what I want access to. That is, I also want my cmake to find the correct Qt, which means setting the CMAKE_PREFIX_PATH environment variable. Yeah, to be honest I'll probably keep my own shell function too. I still need to set the source directory for my shadow builds and it might not be easy to find it with qmake variables. But if it works, I'll replace mine. My whole point here is that developers don't use only qmake, and qmake isn't the only tool that should do different things when a different Qt is desired. You'll want a different toolchain and tools and everything. True, but many of those settings can be found by inferring from qmake. If it doesn't work, then yeah, get the from somewhere else. The easiest way to achieve that is probably to create a solution based on files and you create a ~/.config/qconfig-maemo5 which shadows the one in /etc/qconfig-maemo5 and adds what you want. (Assuming the -add-qt option described below would be implemented to find files like that, but you get the idea). Do you want to store more settings in the config file? Ok... I can consider that a feature request. Therefore, developers will still need to write their own tools which set environment variables (as you can see, I implemented my own tool similar to qset). I don't think there's any point in 'solving' the problem only for finding Qt, and not for the supporting required tools. Oh, yeah, this is based on setting an environment variable. A tool can't set an environment variable, you need to write your own wrapper. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure
On Oct 20, 2012, at 5:18 AM, d3fault d3faultdot...@gmail.com wrote: On Fri, Oct 19, 2012 at 3:37 PM, Knoll Lars lars.kn...@digia.com wrote: This is just wrong, and I'm getting tired of your ramblings on this mailing list. Just because you send something to the ML and people get tired of answering you doesn't mean your proposal is accepted. I was writing that tongue in cheek and mocking Thiago. Sarcasm You. The way you write is quite often rather offensive, and makes people (including myself) ignore any other argument. It's about time you understand that this behaviour is not accepted here and that you will not get anywhere with it. We have a fully worked out proposal by Rich on the table that many people agreed with, and we'll stick with it for now. His proposal is alright, with the exception of handling incoming vulnerabilities. He didn't even discuss the subject, so what do you even mean sticking with it? Lars I'd expect more from you, being the Chief Maintainer of the project and all. What a worthless post. Start with yourself before criticising others. You've had more than your share of worthless (or worse harmful) posts on this list. You didn't even attempt to tackle my argument. No, because I was reacting to your statement about how decisions are being made in this project and the tone of your emails. Speaking of which, if ANYBODY can defeat it, I'll shut up here and now. This is not a mathematical algorithm you can prove right or wrong. Security involves humans and interacting with other people. So there are always arguments speaking for and against certain policies. Read Charley's arguments, he has listed quite a few of the arguments against a public list. For the sake of it here's my summary: Qt is being used in literally millions of places. Most end users do not even know that the product they are using is Qt based. The companies or projects who have developed the software can't really control these usages. Often you can't even easily reach all your customers/users because the only mechanism you have (if there's any at all) is a built-in update mechanism. In many cases it's unreasonable to ask people to shut down the services because it's simply too expensive. Think about a mobile phone like the N9. Do you really expect people to turn their phone off for an unknown amount of time because there's an exploit? Do you think end users can even judge the criticality of the exploit and what kind of measures they could take to avoid it? They can't. Often even we, the main developers behind Qt, can't know what kind of measures and end user needs to use to protect himself, because we don't know how exactly Qt is being used in the product. Of course one needs to publish fixes for security issues and do updates and disclose the problem. But if the issue is not widely known already, we have a chance to already provide a fix when we disclose it. The best way I can see is to keep these private (for a limited period of time) and work with the experts in the area where the issue is to get it fixed as fast as possible. Create the patch and ideally an updated release of the product. Then inform your main customers/users and the rest of the world. Most open source projects use a closed security list for exactly the reasons above. Even Debian who you cite as a reference has it, and they are coordinating disclosure dates with other vendors. Read http://www.debian.org/security/ once again, and don't only cite one sentence in there out of context. So we will be in good company here, following a process very similar to most other OSS projects, including most Linux distributions, WebKit, Apache and many others. And to make it clear: The Qt project will do full disclosure of the issues. The variant we'll be using is in wikipedia called 'Responsible Disclosure'. See http://en.wikipedia.org/wiki/Full_disclosure and http://en.wikipedia.org/wiki/Responsible_disclosure Ok noobs, you leave me no choice. Just like when someone doesn't believe a specific vulnerability is legit, I guess I have to prove it [… deleted pointless rant, threats and insults…] This just makes you sound like a small spoiled child that didn't get his way. And you wonder why people ignore you? Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of ActiveQt
Digia has said that the company is willing to support and maintain the module. It'll be part of the Qt 5 release as well. So it's mainly a problem with the generated documentation currently. Cheers, Lars On Oct 20, 2012, at 2:31 PM, Sze Howe Koh szehowe@gmail.commailto:szehowe@gmail.com wrote: (Re-including the mailing list) The snapshot is the more recent version of the page you linked. But in any case, I found an old thread (http://www.mail-archive.com/development@qt-project.org/msg01737.html), which suggests that there's no active maintainer at the moment. Regards, Sze-Howe On Sat, Oct 20, 2012 at 8:19 PM, 1+1=2 he...@debao.memailto:he...@debao.me wrote: http://qt-project.org/doc/qt-5.0/modules.html On Sat, Oct 20, 2012 at 7:29 PM, Sze Howe Koh szehowe@gmail.commailto:szehowe@gmail.com wrote: Hi all, I'm curious about the status of ActiveQt. The QAxContainer and QAxServer modules seem to still exist in the code base, but aren't listed in http://doc-snapshot.qt-project.org/5.0/modules.html. Is this simply an omission in documentation, or are they being removed? Regards, Sze-Howe ___ Development mailing list Development@qt-project.orgmailto:Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Porting exported qt_[win|mac|x11] functions Qt 5.
On Oct 18, 2012, at 10:07 AM, Sorvig Morten morten.sor...@digia.com wrote: According to git grep Qt 4 has 47 semi-public exported qt_platform functions offering platform-spesific functionality. Most platform code is now in plugins and can no longer export symbols. We need a plan for dealing with these in Qt 5. After a brief investigation these fall into several categories (some are in more than one category): - helper functions for other parts of Qt (qt_win_display_dc?) - utility functions (qt_mac_execute_apple_script, qt_mac_secure_keyboard) - access to Qt platform internals (qt_mac_nativeview_for) - obsolete (qt_mac_from_pascal_string) - strange (qt_mac_resolve_sys which just calls dlsym) Proposed solution 0) Ignore the problem for Qt 5.0. Proposed solution 1) Fix it: - Remove/don't port obsolete functions (we can add them back later if it was a mistake) - Add to QPA where it makes sense. The QPlatformNativeInterface subclasses already gives access to may platform internal objects. - Public compatibility API goes int the platform extras modules. Many of the utility functions can be implemented here as well. - Create extras modules for all platforms (we currently have qtmacextras in the Qt playground) - Add the extras modules to the default Qt 5 distribution. Given the current workload and schedule solution 0) is actually tempting, at least for me. Releasing 5.0 with missing functions will perhaps tell us which ones are in use. I'd say we go with solution (0) for 5.0. But we'll need to pick this up again after the 5.0 release, create the platform specific add-ons and add them to the default distribution. Does anyone want to pick this up? Even if we do, I doubt the things will be ready in time for 5.0. Let's add them afterwards. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
FWIW, +1 - with one modification - reflect at least the minor version in the
install path - so $prefix/libexec/qt5.0, if not $prefix/libexec/qt5.0.0.
I think there is probably a simple rule we could maintain: Keeping the names of
developer visible tools the same is, IHMO, a must. Tools that are not developer
visible, but called through generated build environments (e.g. Makefiles
generated by Qmake) can be changed.
$0.02
Ben
- Original Message -
From: Thiago Macieira thiago.macie...@intel.com
To: development@qt-project.org
Cc:
Sent: Friday, October 19, 2012 7:16 PM
Subject: [Development] New proposal for the tool naming
Starting a new thread with some ideas based on the outcomes of the
discussion.
Many thanks to rittk, Simon, Lars and André who helped come up with this.
Note: this applies to the *tools* only. The library naming and installation
paths for plugins and QML files has remained uncontested so far, so we appear
to have a consensus.
The proposal:
1) we introduce a $libexecdir configuration option to qmake and QLibraryInfo.
For backwards compatibility, this $libexecdir will receive the legacy names
of
QT_INSTALL_BINS and QLibraryInfo::BinariesPath. It will default to
$prefix/libexec/qt5, which some distros will change to
$prefix/lib/qt5/libexec.
This directory is *not* expected to be in $PATH on any system and therefore
the documentation cannot assume it is.
In this directory, we'll install the tools not usually run by the user,
tools
that are often run by other tools. They will keep their current names. These
tools are:
qmake
moc
rcc
uic
qdbusxml2cpp
qdbuscpp2xml
lconvert
lrelease
lupdate
qml*
qhelpgenerator
qhelpconverter
qcollectiongenerator
qdoc
2) the $bindir, defaulting to $prefix/bin, will now be found by qmake
property
QT_INSTALL_APPS and QLibraryInfo::ApplicationsPath. It contains end-user
applications that retain backwards compatibility of purpose as well as
output.
Those applications are:
qdbus
qdbusviewer
designer
assistant
linguist
qglinfo
pixeltool
[creator]
I'm open to suggestions on whether some of the tools should be symlinked
here
(e.g., qmlscene5 - $libexecdir/qmlscene).
3) In addition, we'll create a *new* tool also called qmake that will be
installed to $bindir. This tool shall have the following behaviours:
a) under most circumstances, it will simply find another qmake and pass
through all arguments. That is:
qmake -project
basically will exec
$someotherpath/qmake -project
b) additionally, it accepts an extra argument (-select), which causes it to
select a different Qt version. For example:
qmake -qt=5 -project
qmake -qt=4.8.4 CONFIG+=debug
etc.
As a shorthand, the option -qtX means -qt=X.
This argument will be stripped from the command-line before calling the real
qmake.
Without this option, it will fall back to a well-known environment variable
(say, QT_SELECT=5). And if that is also missing, it selects some
system-defined
or user-defined default.
c) it adds one extra option: -print-versions, which will list which Qt
versions are known to this tool
It is our intention that this new tool replace all pre-existing qmake found
in $PATH. One tool to rule them all. Creator can query this tool to find all
known Qt versions and populate its listing.
In turn, the official Qt 5 documentation should always talk about qmake like
so:
qmake -qt5 LIBS+=-L/usr/local/lib -lmysqlclient_r mysql.pro
This allows the Troll qset function to be implemented like:
function qset() {
local prefix=$(qmake -qt=$1 -query QT_INSTALL_PREFIX)
if [ $? -gt 0 ]; then
echo 2 No such Qt version $1
else
export QT_SELECT=$1
export QTDIR=$prefix
local libdir=$(qmake -query QT_INSTALL_LIBS)
export LD_LIBRARY_PATH=$libdir${LD_LIBRARY_PATH+:$LD_LIBRARY_PATH)
export PKG_CONFIG_PATH=$libdir/pkgconfig:$PKG_CONFIG_PATH
# optional:
#PATH=$(qmake -query QT_INSTALL_BINS):$PATH
fi
}
function qcd() { cd $QTDIR; }
Additionally, this tool may support options like -add-qt and -set-default-qt.
I'm also open to adding an option -run-tool= (e.g., qmake -qt=5 -run-
tool=qmlplugindump) if that's of interest to people.
I haven't decided whether this tool should be a shell script, a perl script
or
another bootstrapped executable.
Please comment.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
