Wiki

Ticket #141 (assigned defect)

Opened 9 years ago

Last modified 4 years ago

Cannot effectively put more options after -turbo

Reported by: Chuck Owned by: nerdzero
Priority: minor Milestone:
Component: Cobra Compiler Version: 0.8.0
Keywords: command-line, turbo Cc:

Description

This command line will still exclude assert statements:

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

Attachments

turbo-plus.patch Download (4.1 KB) - added by hopscc 8 years ago.
ticket141-turbo-plus1.patch Download (9.0 KB) - added by hopscc 8 years ago.

Change History

Changed 8 years ago by hopscc

  • owner set to hopscc
  • status changed from new to assigned

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.

Changed 8 years ago by hopscc

Changed 8 years ago by hopscc

  • owner changed from hopscc to Chuck

code patch, test files. relnote

Changed 8 years ago by Chuck

  • owner changed from Chuck to hopscc

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

Changed 8 years ago by hopscc

  • owner changed from hopscc to Chuck

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

Changed 8 years ago by Chuck

  • owner changed from Chuck to hopscc

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

Changed 8 years ago by hopscc

Changed 8 years ago by hopscc

  • owner changed from hopscc to Chuck

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

Changed 4 years ago by nerdzero

  • owner changed from Chuck to 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.

Changed 4 years ago by 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.

Changed 4 years ago by 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.

Note: See TracTickets for help on using tickets.