Concenrate the use of flags in CLIs #552
Description
Currently, TC makes extensive use of command line flags (provided by gflags) for debugging or configuration purposes. These flags are essentially global variables, and global variables are generally discouraged. In particular, using flags led to linking problems in #541 (attempting to address #456), extra code in #486 and clunky Python API in #531.
I propose to restrict the use of flags to executables with command line interface, tests and examples for now. The flags should not leak to any file other than the one containing the main()
function. One simple solution to that is provide a common header with flags in an anonymous namespace, making each source file that includes the header have its own copy of the flags.
Internally, TC is a compiler that needs a configuration object. (Cuda)MappingOptions
contains the options related to scheduling and code generation, but not to the compiler itself. Warning and debug information emission can be controlled by some TcCompilerOptions
, which can include different output verbosity options. These options can be set up from the command line or programmatically, and passed to tc::compile
. Similarly, TcTunerOptions
should be passed to tc::tune
instead of using global flags. For the latter, Python bindings already have a TunerConfig
class
One particular case to handle is glog dependence on gflags to redirect output.