Details
-
Bug
-
Resolution: Done
-
P2: Important
-
1.9.0
-
None
-
Note that a number of claims in this report are incorrect. This has nothing to do with module merging, and qbs list properties can still be overridden. The only thing that broke is that anything prefixed with "modules." will no longer override prototype defaults. This is due to a simple implementation glitch, rather than a conceptual problem.Note that a number of claims in this report are incorrect. This has nothing to do with module merging, and qbs list properties can still be overridden. The only thing that broke is that anything prefixed with "modules." will no longer override prototype defaults. This is due to a simple implementation glitch, rather than a conceptual problem.
-
548790931ccac858d9244e4c5546ef1664b0dc4a
Description
Since all the module merging stuff, it's now impossible to override list properties on the command line. The values specified on the command line can only be concatenated with the values from modules, but not override them entirely (unless the value comes from a profile, which is unnecessarily verbose and difficult for simple one-off property assignments).
We should have a way to explicitly use the value of a list property from the command line, probably using a new syntax. A possible syntax might be:
qbs qbs.targetOS=:android,linux,unix
...which is similar to the notation used for setting a value in some languages. Or perhaps moving the equals sign to the front:
qbs =qbs.targetOS:android,linux,unix
This specific example relates to QBS-1070, which may have an alternate solution anyways, but I think it is still valuable to solve this for the general case as it may be needed for other properties in certain circumstances.
Attachments
Issue Links
- relates to
-
QBS-1070 qbs.targetOS cannot (only) be a list
-
- Closed
-