Skip to content
This repository has been archived by the owner on Apr 28, 2023. It is now read-only.

Concenrate the use of flags in CLIs #552

Open
ftynse opened this issue Jul 4, 2018 · 0 comments
Open

Concenrate the use of flags in CLIs #552

ftynse opened this issue Jul 4, 2018 · 0 comments
Assignees

Comments

@ftynse
Copy link
Contributor

ftynse commented Jul 4, 2018

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

which should be promoted to C++ API.

One particular case to handle is glog dependence on gflags to redirect output.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants