[Development] New proposal for the tool naming

[Lincoln Ramsay]

Serves me right for not reading _all_ the mail in this folder before 
replying to an old thread...


On 20/10/12 09:16, Thiago Macieira wrote:
> 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

+1

> 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.

+1

Though, I'm not sure we need QT_SELECT. If you can change an environment 
variable, you can modify PATH.

> 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.

+1

> 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 guess -add-qt is more for developer convenience? Under normal 
operation, I'd expect distros to install Qt + 
/etc/xdg/qmake/something.conf for this tool to find.

I suppose set-default-qt is necessarily user-specific.

I'm going to respond here to people asking for directory-specific qmake 
binding:

Just set PATH. Setup a cdrc thing in your shell if you want to automate 
this.

> I haven't decided whether this tool should be a shell script, a perl script or
> another bootstrapped executable.

If this replaces the Qt 4 qmake, it might be problematic to have it 
built from Qt 5 sources. It would need to be statically built and split 
off during packaging so that it had no dependencies on Qt 5. If you can 
achieve that, go ahead and write it in Qt.

-- 
Link