Closed emeryberger closed 7 months ago
I agree that wrapper mode should be default.
Having it precede the compiler command is a good idea but with some caveats when working with build systems: they typically expect a single file/executable for the compiler, hence options cannot be passed then (example: CXX
, CMAKE_CXX_COMPILER
typically expect a single file). This is why the current --wrapper
option generates a dummy Python file that 1. keeps all arguments that were passed to CWhy when creating the wrapper (including the compiler) 2. acts exactly as the original compiler would.
I do think we can make it nicer, but we need to make sure we can still invoke CWhy with build tools.
# Given a compile command.
% [COMPILER] [COMPILER_OPTIONS]
# Current way.
% `cwhy --wrapper --wrapper-compiler=[COMPILER] [CWHY_OPTIONS]` [COMPILER_OPTIONS]
# This is nicer for example.
% cwhy [CWHY_OPTIONS] --- [COMPILER] [COMPILER_OPTIONS]
I'll think about this and try to come up with something.
If we support more languages, I think that sooner or later we will have to select a specific mode for CWhy,with some auto-detection and a --mode
option. I feel like we are bound to have conflicts in regexes, or we might decide to parse output for a certain language / compiler a smarter way.
Wrapper mode has now been default for a bit, closing this.
Custom mode would still be good if we ever decide to be smarter about diagnostic parsing (or if compilers can emit SARIF / JSON).
I am also wondering whether we shouldn't just switch to a mode where we precede any compiler command with
cwhy
and it does the right thing (that is, wrapper-mode would be the default).