Project

General

Profile

artmod-uasge.txt

Christopher Green, 03/08/2011 07:58 AM

 
1
NAME
2
    artmod: Generate clean module source for ART.
3

    
4
SYNOPSIS
5
    artmod -h | --help | -?
6

    
7
    artmod [*optons*] [--] *module-type* *qualified-name*
8

    
9
    *Options*: --boilerplate|-b *file* | --entry[-point[s]]|--entries|-e
10
    *entry-point*+ | header-loc *path* | --split | --split-ext
11
    [*lib-source-extension*] | --verbose|-v
12

    
13
    Options marked with + are repeatable and cumulative.
14

    
15
DESCRIPTION
16
    *artmod* is a tool to produce an ART module source skeleton for an
17
    analyzer, a filter or a producer. The user can specify which entry
18
    points are to be configured and whether to split the source into three
19
    files or combine it into one. In addition, the name of a file wherein
20
    boilerplate comments or code may be found for insertion into the source
21
    may be specified.
22

    
23
  OPTIONS
24
    --boilerplate *file*
25
    -b *file*
26
        Include the specified file as preamble in all generated files.
27

    
28
        Certain format strings will be honored, such as:
29

    
30
          %c  The class name
31
          %C  The qualified class name
32
          %d  The date and time of generation of the module.
33
          %f  The basename of the file in which the boilerplate is
34
                included.
35
          %F  The fully-qualified path of the file in which the
36
                boilerplate is included.
37
          %t  The type of module geerated (analyzer, filter or producer).
38
          %u  The login name of the invoker of artmod.
39
          %U  The full name (if available) if the invoker of artmod, or
40
                the login name if not.
41
          %v  The version of ART from which the generation script came.
42

    
43
        Literal % characters should be escaped (\%).
44

    
45
        If the boilerplate file is not specified artmod will interrogate an
46
        environment variable, "ARTMOD_BOILERPLATE" and attempt to include
47
        the file specified.
48

    
49
        See also --impl-boilerplate, below.
50

    
51
    --entry-list *file*
52
    -E *file*
53
        Specify a file containing a list, one per line, of desired entry
54
        points for the function to be generated. This list will be OR-ed
55
        with any specified on the command line (see -e, below)
56

    
57
    --entry *entry-point*+
58
    --entry-point *entry-point*+
59
    --entry-points *entry-point*+
60
    --entries *entry-point*+
61
    -e *entry-point*+
62
        Specify optional entry points. A recognized entry point will be put
63
        in with the correct siganture; a non-recognized entry point (member
64
        function, for example) will be put in the private section with
65
        either no arguments or the arguments specified if the prototype if
66
        specified in full. For example,
67

    
68
        --entries=beginJob,endJob,reconfigure,\ "bool doPrivateStuff(T1
69
        const &t1, T2 const &t2)"
70

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

    
76
    --impl-boilerplate *file*
77
        Boilerplate specifically for placement prior to the implementation
78
        of the module. In the separate-file mode of operation, the standard
79
        boilerplate will be omitted from the implementation code. The
80
        environment variable ARTMOD_IMPL_BOILERPLATE will be interrogated in
81
        the absence of this option. See the documentation for --boilerplate
82
        above for information about substitutions.
83

    
84
    --split
85
        Produce three files: *class-name*.h, <class-name>*ext* and
86
        *class-name*_module.cc (note you must supply the period yourself).
87
        The default behavior is to produce one file only:
88
        *class-name*_module.cc.
89

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

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

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

    
102
        2.  When both the module implementation and the module macro
103
            invocation are in the <name>_module.cc file, then the module
104
            library contains all the module implementation code and its
105
            dependencies are separate from the dependencies of code in the
106
            package's general code library. This makes for easier
107
            maintenance of package dependencies.
108

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

    
112
    --split-ext *ext*
113
        Change the extension of the class implemenation file from .cxx to
114
        *ext*. Specifying this option automatically implies --split.
115

    
116
    --verbose
117
    -v
118
        Print some extra messages about functions generated, etc. =back
119