vg
tools for working with variation graphs
|
#include <map>
#include <functional>
#include <string>
#include <iostream>
Classes | |
class | vg::subcommand::Subcommand |
Namespaces | |
vg | |
vg::subcommand | |
Enumerations | |
enum | vg::subcommand::CommandCategory { vg::subcommand::PIPELINE, vg::subcommand::TOOLKIT, vg::subcommand::WIDGET, vg::subcommand::DEVELOPMENT, vg::subcommand::DEPRECATED } |
Functions | |
std::ostream & | vg::subcommand::operator<< (std::ostream &out, const CommandCategory &category) |
Define a way to print the titles of the different categories. More... | |
subcommand.hpp: defines a system for registering subcommands of the vg command (vg construct, vg view, etc.) at compile time. Replaces the system of defining two functions and a giant run of if statements in main.cpp.
main.cpp does not need to include any subcommand headers!
Subcommands are created as static global objects in their own compilation units, which have to be explicitly linked into the binary (they won't be pulled out of a library if nothing references their symbols).
Subcommands are responsible for printing their own help; we can do "vg help" and print all the subcommands that exist (via a help subcommand), but we can't do "vg help subcommand" and have that be equivalent to "vg subcommand --help" (because the help subcommand doesn't know how to get help info on the others).
We have a subcommand importance/category system, so we can tell people about just the main pipeline and keep the subcommands they don't want out of their brains and off their screen.
Subcommands get passed all of argv, so they have to skip past their names when parsing arguments.
To make a subcommand, do something like this in a cpp file in this "subcommand" directory:
#include "subcommand.hpp" using namespace vg::subcommand; int main_frobnicate(int argc, char** argv) { return 0; } static Subcommand vg_frobnicate("frobnicate", "frobnicate nodes and edges", main_frobnicate);