Details
-
Suggestion
-
Resolution: Unresolved
-
Not Evaluated
-
None
-
2.0
-
None
Description
There are several problems with the current frontend.
- As discussed in
QBS-1624, it is not convenient to change resolve props via "qbs prop:value" syntax as it complains that props are changed. As mentioned, the problem comes from the fact that "qbs build" allows "prop:value" syntax in the first place. - qbs resolve --help doesn't work, see
QBS-504 - There are problems with formatting on Windows QBS-511
Suggested solutions.
- Use Qt command line parser instead of a custom one.
- "qbs help <command>" should call "qbs <command> --help"
- Separate "qbs build" and "qbs resolve" commands in a way that it is not possible to pass "prop:value" to build command. Also, resolve params such as "-f" should also be removed.
- Do not allow "prop:value" syntax for "qbs" (without subcommand) call.
- Basically, "qbs" should be an alias for "qbs build". In order to make simple usage simple, "qbs build" can resolve the project first with empty args if it hasn't been resolved yet (e.g. when "default"/config dir is missing).
In order to do the transition gracefully, first we can introduce separate "qbs-resolve" and "qbs-build" tools. Second, we introduce a mode (via env variable) so that qbs <command> calls "qbs-resolve" or "qbs-build" leaving the old behaviour but we start printing a warning when old syntax is used (unless env forces to use the old syntax). Third, we flip the default env mode to use the new syntax. Forth, we remove the old syntax.