[1] | 1 | |
---|
| 2 | //----------------------------------------------------------- |
---|
| 3 | // Copyright Christian Arnault LAL-Orsay CNRS |
---|
| 4 | // arnault@lal.in2p3.fr |
---|
| 5 | // See the complete license in cmt_license.txt "http://www.cecill.info". |
---|
| 6 | //----------------------------------------------------------- |
---|
| 7 | |
---|
| 8 | ========================================================================== |
---|
| 9 | Flow in cmt_parser |
---|
| 10 | |
---|
| 11 | -------------------------------------- |
---|
| 12 | Cmt::parser (command_line) |
---|
| 13 | split command line into a vector of args |
---|
| 14 | call parser (args) |
---|
| 15 | |
---|
| 16 | -------------------------------------- |
---|
| 17 | Cmt::parser (args) |
---|
| 18 | init ArgParser |
---|
| 19 | call clear |
---|
| 20 | call configure |
---|
| 21 | set m_current_access to user or developer mode |
---|
| 22 | parse_arguments |
---|
| 23 | handle extra lines or extra requirements |
---|
| 24 | |
---|
| 25 | call use_cmt and use_home is needed |
---|
| 26 | select recursive |
---|
| 27 | reach current package and call use_user_context if needed |
---|
| 28 | |
---|
| 29 | detect error if needed |
---|
| 30 | |
---|
| 31 | execute action |
---|
| 32 | |
---|
| 33 | |
---|
| 34 | -------------------------------------- |
---|
| 35 | |
---|
| 36 | |
---|
| 37 | |
---|
| 38 | ========================================================================== |
---|
| 39 | Gestionnaire de messages de log dans CMT |
---|
| 40 | ---------------------------------------- |
---|
| 41 | |
---|
| 42 | cmt_log (...) |
---|
| 43 | |
---|
| 44 | will |
---|
| 45 | |
---|
| 46 | o display or not according to the level of output |
---|
| 47 | |
---|
| 48 | [default] quiet |
---|
| 49 | verbose = <n> |
---|
| 50 | debug |
---|
| 51 | |
---|
| 52 | o pour le mode debug on devrait rajouter la fonction?? |
---|
| 53 | |
---|
| 54 | A terme doit remplacer tous les outputs de CMT !!! |
---|
| 55 | |
---|
| 56 | |
---|
| 57 | ========================================================================== |
---|
| 58 | 1) actions in CMT [DONE] |
---|
| 59 | ----------------- |
---|
| 60 | Principle: |
---|
| 61 | define an "action" concept similar to constituents (or macro????) |
---|
| 62 | |
---|
| 63 | - it has a name |
---|
| 64 | |
---|
| 65 | - its name corresponds to a make target |
---|
| 66 | |
---|
| 67 | - it receives in its value a shell command (subject to macro |
---|
| 68 | expansion before activation) |
---|
| 69 | |
---|
| 70 | - can be run out of the make context through the "cmt do <action>" command. |
---|
| 71 | |
---|
| 72 | - in the context of gmake a temporary make fragment will be |
---|
| 73 | generated, holding the associated shell command. |
---|
| 74 | |
---|
| 75 | |
---|
| 76 | examples |
---|
| 77 | |
---|
| 78 | action A "xxx" WIN32 "yyy" |
---|
| 79 | |
---|
| 80 | => the syntax is like macros but the execution phase is close to constituents. |
---|
| 81 | |
---|
| 82 | One may either do |
---|
| 83 | |
---|
| 84 | > cmt do A |
---|
| 85 | |
---|
| 86 | or |
---|
| 87 | |
---|
| 88 | gmake A |
---|
| 89 | |
---|
| 90 | Question : do we need parameters |
---|
| 91 | |
---|
| 92 | action A "xxx<p>" WIN32 "yyy<p>" |
---|
| 93 | action A "xxx$(p)" WIN32 "yyy$(p)" |
---|
| 94 | |
---|
| 95 | so that |
---|
| 96 | |
---|
| 97 | > cmt do A p=z |
---|
| 98 | > gmake A p=z |
---|
| 99 | |
---|
| 100 | Question : can action replace setup_script ? |
---|
| 101 | |
---|
| 102 | Implementation : reuse the symbol code. |
---|
| 103 | |
---|
| 104 | Cmt::do_do (...) |
---|
| 105 | o at least first argument should be the action name |
---|
| 106 | o optional param-value pairs will assign value to macros |
---|
| 107 | |
---|
| 108 | cmt do A p=y |
---|
| 109 | |
---|
| 110 | equivalent to [macro p "y"] |
---|
| 111 | |
---|
| 112 | cmt show constituents should show actions as well |
---|
| 113 | |
---|
| 114 | when generating the constituent make files we also have to generate |
---|
| 115 | makefiles for actions. |
---|
| 116 | => name space for actions share the name space for constituents |
---|
| 117 | => there is a target_<action> tag [see next design] |
---|
| 118 | |
---|
| 119 | Actually, doing |
---|
| 120 | |
---|
| 121 | action A "cmd" |
---|
| 122 | |
---|
| 123 | is equivalent to doing: |
---|
| 124 | |
---|
| 125 | document cmt_action_runner A action_value='cmd' |
---|
| 126 | |
---|
| 127 | ========================================================================== |
---|
| 128 | 2) target tags DONE |
---|
| 129 | -------------- |
---|
| 130 | Principle: |
---|
| 131 | |
---|
| 132 | - Each constituent (or action) is associated with a make target |
---|
| 133 | |
---|
| 134 | - let's also generate a "tag" associated with the make target. |
---|
| 135 | |
---|
| 136 | - the tag format is target_<name> |
---|
| 137 | |
---|
| 138 | - the group tags are also defined as tag associations |
---|
| 139 | |
---|
| 140 | tag target_all target_A target_B |
---|
| 141 | |
---|
| 142 | ========================================================================== |
---|
| 143 | 3) A pattern also defines a dynamic CMT keyword.[DONE] |
---|
| 144 | |
---|
| 145 | => at the end of the parser if the word did not match any standard |
---|
| 146 | CMT keyword, then we look into the pattern name space. |
---|
| 147 | |
---|
| 148 | ex. |
---|
| 149 | |
---|
| 150 | pattern A ... |
---|
| 151 | |
---|
| 152 | apply_pattern A p=x |
---|
| 153 | |
---|
| 154 | is equivalent to |
---|
| 155 | |
---|
| 156 | A p=x |
---|
| 157 | |
---|
| 158 | ========================================================================== |
---|
| 159 | 4) Revival of the concept of Project[DONE] |
---|
| 160 | |
---|
| 161 | o One project is associated with every CMTPATH |
---|
| 162 | |
---|
| 163 | o Strategies are stored into project objects |
---|
| 164 | |
---|
| 165 | o project objects are ordered like CMTPATHs |
---|
| 166 | |
---|
| 167 | o Each CMTPATH entry does generate one Project |
---|
| 168 | |
---|
| 169 | o unnamed projects receive a default name [TBD] |
---|
| 170 | |
---|
| 171 | o Projects can be named: |
---|
| 172 | |
---|
| 173 | project abcd |
---|
| 174 | |
---|
| 175 | Will name the project associated with the cmtpath of the package where this is defined. |
---|
| 176 | |
---|
| 177 | o By default Projects inherit properties of the previous project |
---|
| 178 | |
---|
| 179 | o Any package has a corresponding project which is the project |
---|
| 180 | associated with the CMTPATH entry of this package. |
---|
| 181 | |
---|
| 182 | o CMT itself defines the "base" project (named CMT) |
---|
| 183 | |
---|
| 184 | |
---|
| 185 | |
---|
| 186 | |
---|
| 187 | |
---|
| 188 | |
---|
| 189 | |
---|