| 50 | | |
| 51 | | You can add files to the !RefactorErl database by calling the |
| 52 | | add function with either a filename as a string or a module name as an atom. |
| 53 | | Note that in the latter case, "ri" defaults to the current working directory |
| 54 | | (which you may work around by including a path in your singe-quoted atom). |
| 55 | | If you specify a directory instead of a regular filename, then it will be recursively |
| 56 | | traversed. You may just as well give a list of atoms or strings to add more files |
| 57 | | at once. All of the following example commands would add the same file: |
| 58 | | |
| 59 | | {{{ |
| 60 | | #!erlang |
| 61 | | cd(dir), ri:add(modname). |
| 62 | | ri:add('dir/modname'). |
| 63 | | ri:add(['dir/modname']). |
| 64 | | ri:add("dir/modname.erl"). |
| 65 | | ri:add("/current/dir/modname.erl"). |
| 66 | | ri:add("path_to_dir/dir"). |
| 67 | | }}} |
| 68 | | |
| 69 | | The module displays the progression of loading. |
| 70 | | Removing files from the database is similarly easy and also recursive. |
| 71 | | The following will equally work: |
| 72 | | |
| 73 | | {{{ |
| 74 | | #!erlang |
| 75 | | ri:drop(modname). |
| 76 | | ri:drop([modname]). |
| 77 | | ri:drop("dir/modname.erl"). |
| 78 | | ri:drop("/current/dir/modname.erl"). |
| 79 | | ri:drop("path_to_dir/dir"). |
| 80 | | }}} |
| 81 | | |
| 82 | | Modules can be loaded as applications, but the base of your library has to |
| 83 | | be set before: |
| 84 | | |
| 85 | | {{{ |
| 86 | | #!erlang |
| 87 | | ri:addenv(appbase, "path/to/my/applib"). |
| 88 | | }}} |
| 89 | | |
| 90 | | If the application has additional include directories, then these directories has to be also set in advance: |
| 91 | | |
| 92 | | {{{ |
| 93 | | #!erlang |
| 94 | | ri:addenv(include, "path/to/my/incldir"). |
| 95 | | }}} |
| 96 | | |
| 97 | | If the application build process contains compile-time macros, then these macros also can be set: |
| 98 | | |
| 99 | | {{{ |
| 100 | | #!erlang |
| 101 | | %if it is only used in ifdef forms. |
| 102 | | ri:addenv(def, 'my_macro'). |
| 103 | | |
| 104 | | ri:addenv(def, {'my_macro', my_macro_value}). |
| 105 | | }}} |
| 106 | | |
| 107 | | If the include forms of the application contain OS based enviromental nodes, then these nodes can be set: |
| 108 | | |
| 109 | | {{{ |
| 110 | | #!erlang |
| 111 | | ri:addenv(env_var, {os_env_name, "os_env_path"}). |
| 112 | | }}} |
| 113 | | |
| 114 | | Let's see an example: |
| 115 | | |
| 116 | | The Emakefile has the following contents: |
| 117 | | {{{ |
| 118 | | #!erlang |
| 119 | | |
| 120 | | {"/home/user/dev/lib/app1/src/*", |
| 121 | | [{i,"/home/user/dev/lib/"}, |
| 122 | | {d,'MY_MACRO', "ITS_VALUE"}, |
| 123 | | {outdir,"/home/user/dev/lib/app1/ebin"}]}. |
| 124 | | |
| 125 | | {"/home/user/dev/lib/app2/src/*", |
| 126 | | [{i,"/home/user/dev/lib/"}, |
| 127 | | {d,'MY_MACRO', "ITS_VALUE"}, |
| 128 | | {outdir,"/home/user/dev/lib/app2/ebin"}]}. |
| 129 | | |
| 130 | | {"/home/user/dev/lib/app3/src/*", |
| 131 | | [{i,"/home/user/dev/lib/share/include/"}, |
| 132 | | {i,"/home/user/dev/lib/"}, |
| 133 | | {outdir,"/home/user/dev/lib/app3/ebin"}]}. |
| 134 | | }}} |
| 135 | | |
| 136 | | To add {{{app1}}}, {{{app2}}}, {{{app3}}} to !RefactorErl you should do the followings: |
| 137 | | {{{ |
| 138 | | #!erlang |
| 139 | | |
| 140 | | % add app1, app2 with the same configuration |
| 141 | | ri:addenv(appbase, "/home/user/dev/lib/"), |
| 142 | | ri:addenv(def, {'MY_MACRO', "ITS_VALUE"}), |
| 143 | | |
| 144 | | Apps = [app1, app2], |
| 145 | | [ri:add(home, App) || App <- Apps]. |
| 146 | | |
| 147 | | % add app3 after the configuration has been modified |
| 148 | | ri:delenv(def), |
| 149 | | ri:addenv(include, "/home/user/dev/lib/share/include/"), |
| 150 | | |
| 151 | | ri:add(home, app3). |
| 152 | | |
| 153 | | }}} |
| 154 | | |
| 155 | | |
| 156 | | You can check the already given application base directories by listing all of the enviromental nodes: |
| 157 | | |
| 158 | | {{{ |
| 159 | | #!erlang |
| 160 | | ri:envs(). |
| 161 | | }}} |
| 162 | | |
| 163 | | It is possible to delete the defined environment variables: |
| 164 | | |
| 165 | | {{{ |
| 166 | | #!erlang |
| 167 | | ri:delenv(include). |
| 168 | | }}} |
| 169 | | |
| 170 | | Or you can set an environmental variable to another value: |
| 171 | | {{{ |
| 172 | | #!erlang |
| 173 | | ri:setenv(env_name, "path/to/new_value"). |
| 174 | | }}} |
| 175 | | |
| 176 | | {{{ |
| 177 | | #!comment |
| 178 | | The following enviromental nodes can be set via the {{{ri}}} module: |
| 179 | | |
| 180 | | {{{output}}}: Where does RefactorErl write changes in? |
| 181 | | |
| 182 | | {{{appbase}}}: The list of the used application based directories. |
| 183 | | |
| 184 | | {{{include}}}: The list of the used include directories. |
| 185 | | |
| 186 | | {{{def}}}: The list of the compile-time macros. |
| 187 | | |
| 188 | | {{{env_var}}}: The list of the OS based enviromental nodes. |
| 189 | | |
| 190 | | }}} |
| 191 | | |
| 192 | | {{{ |
| 193 | | #!comment |
| 194 | | Let's see an example: |
| 195 | | |
| 196 | | {{{ |
| 197 | | #!erlang |
| 198 | | % Here 'appbase' contains 'usr'. |
| 199 | | (refactorerl@localhost)18> ri:envs(). |
| 200 | | output = original |
| 201 | | appbase = "/usr/local/lib/erlang/lib" |
| 202 | | |
| 203 | | (refactorerl@localhost)19> ri:add(usr, synatx_tools). |
| 204 | | Application synatx_tools not found under usr |
| 205 | | not_found |
| 206 | | |
| 207 | | % 'appbase' contains 'usr', so syntax_tools will be loaded from |
| 208 | | % '/usr/local/lib/erlang/lib' |
| 209 | | (refactorerl@localhost)20> ri:add(usr, syntax_tools). |
| 210 | | Adding: /usr/local/lib/erlang/lib/syntax_tools-1.6.7.1/src |
| 211 | | ... |
| 212 | | }}} |
| 213 | | }}} |
| 214 | | |
| 215 | | For convenience, both the filenames and the directory names can be given |
| 216 | | as atoms as well as strings. |
| 217 | | The list of loaded files can be obtained by calling |
| 218 | | |
| 219 | | {{{ |
| 220 | | #!erlang |
| 221 | | ri:ls(). |
| 222 | | }}} |
| 223 | | |
| 224 | | This call also displays the status of the loaded files (error or no_error). |
| 225 | | If the module m is loaded, |
| 226 | | |
| 227 | | {{{ |
| 228 | | #!erlang |
| 229 | | ri:ls(m). |
| 230 | | }}} |
| 231 | | |
| 232 | | will give information about the functions, records and macros in the file. |
| 233 | | The contents of a file can be listed by |
| 234 | | |
| 235 | | {{{ |
| 236 | | #!erlang |
| 237 | | ri:cat(ModFile). |
| 238 | | }}} |
| 239 | | |
| 240 | | The content of a function can be listed by |
| 241 | | |
| 242 | | {{{ |
| 243 | | #!erlang |
| 244 | | ri:cat(ModFile, {FunName,Arity}). |
| 245 | | }}} |
| 246 | | |
| 247 | | Usually, Erlang source files (having the extension |
| 248 | | .erl) are loaded into !RefactorErl. In addition, !RefactorErl is also capable of |
| 249 | | loading compiled .beam files. |
| 250 | | |
| 251 | | {{{ |
| 252 | | #!erlang |
| 253 | | ri:add("compiled.beam"). |
| 254 | | }}} |
| 255 | | |
| 256 | | Note that this feature is applicable only to those .beam files that were compiled |
| 257 | | with the debug_info option. Also note that the resulting file will be pretty |
| 258 | | printed by !RefactorErl. |
| | 50 | See [wiki:ManagingFiles Managing your files and applications]. |
