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

Concenrate the use of flags in CLIs #552

Open
@ftynse

Description

@ftynse

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.

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions