Project

General

Profile

cetskelgen

Usage

NAME
    cetskelgen: Generate clean plugin source for art.

SYNOPSIS
    cetskelgen -h | --help | -?

    cetskelgen --help-types

    cetskelgen --help-type plugin-type

    cetskelgen [options] [--] [plugin-type[:plugin-option[,plugin-option]+]]
    qualified-name

    Options: --all-entries|-A | --boilerplate|-b file |
    --entries|--entry|-e entry+ | --header-loc path |
    --output-dir|--dir|-d dir | --split | --split-ext [lib-source-extension] |
    --verbose|-v

    Options marked with + are repeatable and cumulative.

DESCRIPTION
    cetskelgen is a tool to produce an art plugin source skeleton for an
    analyzer, a filter or a producer. The user can specify which optional
    member functions are to be configured and whether to split the source into
    three files or combine it into one. In addition, the name of a file
    wherein boilerplate comments or code may be found for insertion into the
    source may be specified.

  HELP OPTIONS
    --help
        This help.

    --help-types
        Display each available plugin type, with required and optional
        interface.

  ARGUMENTS
    plugin-type
        The type of the plugin to be generated. See the --help-types option.

    qualified-name
        The namespace-qualified class name (eg ns1::ns2::MyClass).

  OPTIONS
    --all-entries
    -A  Include all optional entry points for the specified plugin type.

    --boilerplate file
    -b file
        Include the specified file as preamble in all generated files.

        Certain format strings will be honored, such as:

          %%  A literal %.
          %c  The class name.
          %C  The qualified class name.
          %d  The date and time of generation of the plugin.
          %f  The basename of the file in which the boilerplate is
                included.
          %F  The fully-qualified path of the file in which the
                boilerplate is included.
          %n  The qualification (namespace chain) of the class (:: if empty).
          %p  The product whence came cetskelgen
          %P  The product whence came the plugin information.
          %t  The type of plugin generated.
          %u  The login name of the invoker of cetskelgen.
          %U  The full name (if available) if the invoker of cetskelgen, or
                the login name if not.
          %v  The version of the package whence came cetskelgen.
          %V  The version of the package whence came the plugin information.

        Literal % characters may also be escaped (\%).

        If the boilerplate file is not specified cetskelgen will interrogate
        an environment variable, "CETSKEL_BOILERPLATE" and attempt to include
        the file specified. If that is also not found, cetskelgen will use an
        internal default.

        See also --impl-boilerplate, below.

    --entry-list file
    -E file
        Specify a file containing a list, one per line, of desired member
        functions or data for the class to be generated. This list will be
        OR-ed with any specified on the command line (see -e, below)

    --entries entry+
    --entry entry+
    -e entry+
        Specify optional member functions or data. A recognized entry will be
        put in with the correct siganture; a non-recognized entry (member
        function, for example) will be put in the private section as either a
        member function or member data depending on the presence of
        parentheses. For example,

        -e beginJob -e endJob -e reconfigure -e "bool doPrivateStuff(T1 const&
        t1, T2 const& t2)" -e "std::vector<int> privateData_" 

    --force
    -f  Force overwrite of existing files; the default is to not overwrite.

    guard header-guard-spec
        The specification for the header guard. '%' format specifiers are
        honored, as are the Perl-regex directives \U, \L and \E. Ignored
        unless the --split option is used. The environment variable
        CETSKEL_HEADER_GUARD will be interrogated in the absence of this
        option, and failing, that the default will be the header file's path
        from package-top. See the documentation for --boilerplate above for
        information about substitutions.

    --header-loc path
        The path part of the header include directive for the class definition
        (eg art/Framework/Core). Ignored unless the --split option is used.

    --impl-boilerplate file
        Boilerplate specifically for placement prior to the implementation of
        the plugin. In the separate-file mode of operation, the standard
        boilerplate will be omitted from the implementation code. The
        environment variable CETSKEL_IMPL_BOILERPLATE will be interrogated in
        the absence of this option. See the documentation for
        --boilerplate above for information about substitutions.

    --output-dir dir
    --dir dir
    -d dir
        Place the generated output files in the specified directory instead of
        the current one. Note that in the case of split files (see --split
        below), the path will not be reflected in the #include statement of
        the header in the .cxx and .cc files. To specify a path (usually
        relative to the top of the package) in the #include statement, use the
        ---header-loc option.

    --split
        Produce three files: class-name.h, <class-name>ext and
        class-name_<plugin-suffix>.cc (note you must supply the period
        yourself). The default behavior is to produce one file only:
        class-name_<plugin-suffix>.cc.

        One complication of using this option is that, in order to properly
        specify the header location (package/[dir]+) as required by the
        implementation and plugin registration files, you will need to use the
        --header-loc option described above.

        Before you use this item, note that there are several advantages to
        the one-file philosophy in this case:

        1.  The only communication with a plugin should be via the run, the
            subrun and/or the event. Having the class definition in the same
            file as its implmenetation helps enforce this.

        2.  When both the plugin implementation and the plugin macro
            invocation are in the <name>_<plugin-suffix>.cc file, then the
            plugin library contains all the plugin implementation code and its
            dependencies are separate from the dependencies of code in the
            package's general code library. This makes for easier maintenance
            of package dependencies.

            The default value of ext is ".cxx" unless changed with
            --split-ext, below.

    --split-ext ext
        Change the extension of the class implemenation file from .cxx to ext.
        Specifying this option automatically implies --split.

    --verbose
    -v  Print some extra messages about functions generated, etc.

Examples

  • cetskelgen --help-types
    Display currently-understood plugin types, and their usage.
  • cetskelgen -v -d srcs/mypkg/mypkg -e beginJob -e endJob analyzer myns::FancyAnalyzer
    Generate srcs/mypkg/mypkg/FancyAnalyzer_module.cc with entry points analyze(), beginJob() and endJob(), with their correct signatures.