Cannot effectively put more options after -turbo

[Chuck]

This command line will still exclude assert statements:

cobra -turbo -include-asserts:yes foo.cobra

[hopscc]

The problem here is that the options generated from -turbo are overwriting any of the same options set individually anywhere on the commandline.
In turbo processing needs a check that these options were not individually set before setting them as per the turbo settings.

[hopscc]

code patch, test files. relnote

[Chuck]

Looking at the implementation in the patch stimulates this question: Does this patch shift the bug so that "cobra -include-asserts:yes -turbo" now acts incorrectly?

Note that putting -turbo before or after other options can easily come up via build scripts which might include one or the other, but also take additional args on the command line:

#!/bin/bash
cobra -turbo $@ foo bar

[hopscc]

Only if you work from the assumption that interacting options are applied sequentially
LtoR and that composite/compounding options (only -turbo (?))
have same priority as single ones.

My thinking here was that a single option anywhere on the command line trumps/overrides the same option buried in a compound (convenience) option because its explicitly specified.

For your example above I'd imagine the expectation was for that to be the case ..
( compile with all turbo options except where specified+overridden explicitly )
though that also comes from the expectation of LtoR processing..

[Chuck]

I'm definitely thinking LtoR on options even if they are "meta-options".

[hopscc]

code patch for inline turbo handling, subsequent code cleanup,refactoring, extend test file, relnote

[nerdzero]

From reviewing the patch there is a minor tweak required due to changeset 2942. -turbo no longer sets -include-traces:no

I'll try and figure out how to update the patch. My command-line-svn-fu is weak.

[Charles]

My most commonly used svn commands are:

svn up
svn diff > r.diff
svn ci
svn ci <filenames>
svn revert <filename>
svn resolved <filename>

You need to do "svn up" from the top level directory. Likewise with "svn ci" being done in the topmost directory that captures your changes, which will typically also be the top directory.

And for "diff" I like to have more context so I actually have a "di" script which does:
svn diff --diff-cmd diff --extensions '-U 5' "$@"

HTH

If this was helpful at all I guess we could move it to a wiki page.

[nerdzero]

Thanks, but I meant for updating the attached .patch file so it will apply without issues. In the interest of time, I'll just redo the changes manually and then create a new patch.