| | 1 | = Managing your files and applications = |
| | 2 | |
| | 3 | == Adding files and directories == |
| | 4 | |
| | 5 | You can add files to the !RefactorErl database by calling the |
| | 6 | add function with either a filename as a string or a module name as an atom. |
| | 7 | Note that in the latter case, "ri" defaults to the current working directory |
| | 8 | (which you may work around by including a path in your singe-quoted atom). |
| | 9 | If you specify a directory instead of a regular filename, then it will be recursively |
| | 10 | traversed. You may just as well give a list of atoms or strings to add more files |
| | 11 | at once. All of the following example commands would add the same file: |
| | 12 | |
| | 13 | {{{ |
| | 14 | #!erlang |
| | 15 | cd(dir), ri:add(modname). |
| | 16 | ri:add('dir/modname'). |
| | 17 | ri:add(['dir/modname']). |
| | 18 | ri:add("dir/modname.erl"). |
| | 19 | ri:add("/current/dir/modname.erl"). |
| | 20 | ri:add("path_to_dir/dir"). |
| | 21 | }}} |
| | 22 | |
| | 23 | Usually, Erlang source files (having the extension |
| | 24 | .erl) are loaded into !RefactorErl. In addition, !RefactorErl is also capable of |
| | 25 | loading compiled .beam files. |
| | 26 | |
| | 27 | {{{ |
| | 28 | #!erlang |
| | 29 | ri:add("compiled.beam"). |
| | 30 | }}} |
| | 31 | |
| | 32 | Note that this feature is applicable only to those .beam files that were compiled |
| | 33 | with the debug_info option. Also note that the resulting file will be pretty |
| | 34 | printed by !RefactorErl. |
| | 35 | |
| | 36 | == Dropping files and directories == |
| | 37 | |
| | 38 | The module displays the progression of loading. |
| | 39 | Removing files from the database is similarly easy and also recursive. |
| | 40 | The following will equally work: |
| | 41 | |
| | 42 | {{{ |
| | 43 | #!erlang |
| | 44 | ri:drop(modname). |
| | 45 | ri:drop([modname]). |
| | 46 | ri:drop("dir/modname.erl"). |
| | 47 | ri:drop("/current/dir/modname.erl"). |
| | 48 | ri:drop("path_to_dir/dir"). |
| | 49 | }}} |
| | 50 | |
| | 51 | == Adding applications == |
| | 52 | |
| | 53 | Modules can be loaded as applications, but some configurations has to be made before. |
| | 54 | The configurations can be done manually by setting the enviromental nodes, or can be done automatically by using the [http://www.erlang.org/doc/man/make.html Emakefile] handling functions (beta version) of the tool. |
| | 55 | |
| | 56 | === Adding applications by manual configuration === |
| | 57 | |
| | 58 | The manually configuration can be done by using the {{{ri}}} or the {{{ris}}} module. |
| | 59 | |
| | 60 | Modules can be loaded as applications, but the base of your library has to |
| | 61 | be set before: |
| | 62 | |
| | 63 | {{{ |
| | 64 | #!erlang |
| | 65 | ri:addenv(appbase, "path/to/my/applib"). |
| | 66 | }}} |
| | 67 | |
| | 68 | If the application has additional include directories, then these directories has to be also set in advance: |
| | 69 | |
| | 70 | {{{ |
| | 71 | #!erlang |
| | 72 | ri:addenv(include, "path/to/my/incldir"). |
| | 73 | }}} |
| | 74 | |
| | 75 | If the application build process contains compile-time macros, then these macros also can be set: |
| | 76 | |
| | 77 | {{{ |
| | 78 | #!erlang |
| | 79 | %if it is only used in ifdef forms. |
| | 80 | ri:addenv(def, 'my_macro'). |
| | 81 | |
| | 82 | ri:addenv(def, {'my_macro', my_macro_value}). |
| | 83 | }}} |
| | 84 | |
| | 85 | If the include forms of the application contain OS based enviromental nodes, then these nodes can be set: |
| | 86 | |
| | 87 | {{{ |
| | 88 | #!erlang |
| | 89 | ri:addenv(env_var, {os_env_name, "os_env_path"}). |
| | 90 | }}} |
| | 91 | |
| | 92 | Let's see an example: |
| | 93 | |
| | 94 | The Emakefile has the following contents: |
| | 95 | {{{ |
| | 96 | #!erlang |
| | 97 | |
| | 98 | {"/home/user/dev/lib/app1/src/*", |
| | 99 | [{i,"/home/user/dev/lib/"}, |
| | 100 | {d,'MY_MACRO', "ITS_VALUE"}, |
| | 101 | {outdir,"/home/user/dev/lib/app1/ebin"}]}. |
| | 102 | |
| | 103 | {"/home/user/dev/lib/app2/src/*", |
| | 104 | [{i,"/home/user/dev/lib/"}, |
| | 105 | {d,'MY_MACRO', "ITS_VALUE"}, |
| | 106 | {outdir,"/home/user/dev/lib/app2/ebin"}]}. |
| | 107 | |
| | 108 | {"/home/user/dev/lib/app3/src/*", |
| | 109 | [{i,"/home/user/dev/lib/share/include/"}, |
| | 110 | {i,"/home/user/dev/lib/"}, |
| | 111 | {outdir,"/home/user/dev/lib/app3/ebin"}]}. |
| | 112 | }}} |
| | 113 | |
| | 114 | To add {{{app1}}}, {{{app2}}}, {{{app3}}} to !RefactorErl you should do the followings: |
| | 115 | {{{ |
| | 116 | #!erlang |
| | 117 | |
| | 118 | % add app1, app2 with the same configuration |
| | 119 | ri:addenv(appbase, "/home/user/dev/lib/"), |
| | 120 | ri:addenv(def, {'MY_MACRO', "ITS_VALUE"}), |
| | 121 | |
| | 122 | Apps = [app1, app2], |
| | 123 | [ri:add(home, App) || App <- Apps]. |
| | 124 | |
| | 125 | % add app3 after the configuration has been modified |
| | 126 | ri:delenv(def), |
| | 127 | ri:addenv(include, "/home/user/dev/lib/share/include/"), |
| | 128 | |
| | 129 | ri:add(home, app3). |
| | 130 | |
| | 131 | }}} |
| | 132 | |
| | 133 | |
| | 134 | You can check the already given application base directories by listing all of the enviromental nodes: |
| | 135 | |
| | 136 | {{{ |
| | 137 | #!erlang |
| | 138 | ri:envs(). |
| | 139 | }}} |
| | 140 | |
| | 141 | It is possible to delete the defined environment variables: |
| | 142 | |
| | 143 | {{{ |
| | 144 | #!erlang |
| | 145 | ri:delenv(include). |
| | 146 | }}} |
| | 147 | |
| | 148 | Or you can set an environmental variable to another value: |
| | 149 | {{{ |
| | 150 | #!erlang |
| | 151 | ri:setenv(env_name, "path/to/new_value"). |
| | 152 | }}} |
| | 153 | |
| | 154 | |
| | 155 | The following enviromental nodes can be set via the {{{ri}}} module: |
| | 156 | |
| | 157 | {{{output}}}: Where does !RefactorErl write changes in? |
| | 158 | |
| | 159 | {{{appbase}}}: The list of the used application based directories. |
| | 160 | |
| | 161 | {{{include}}}: The list of the used include directories. |
| | 162 | |
| | 163 | {{{def}}}: The list of the compile-time macros. |
| | 164 | |
| | 165 | {{{env_var}}}: The list of the OS based enviromental nodes. |
| | 166 | |
| | 167 | |
| | 168 | === Adding applications using the Emakefile handling functions === |
| | 169 | Applications with their proper configurations (such as include paths, macros), or only the configurations, which are defined |
| | 170 | in an Emakefile, can be added by executing only one command. |
| | 171 | The given Emakefile is parsed then the configurations and the adding procedure are handled automatically by the tool. |
| | 172 | The functionality is available in the ri module and also available in the ris module. |
| | 173 | |
| | 174 | By executing one of the following commands: |
| | 175 | |
| | 176 | {{{ |
| | 177 | #!erlang |
| | 178 | EmakeFilePath = "/absolute_path_to_the_emakefile", |
| | 179 | ri:add_by_emakefile(EmakefilePath). |
| | 180 | |
| | 181 | % whether a list of Emakefiles are present. |
| | 182 | EmakeFiles = ["/absolute_path_to_the_emakefile1", "/absolute_path_to_the_emakefile2"], |
| | 183 | ri:add_by_emakefile(EmakeFiles). |
| | 184 | |
| | 185 | }}} |
| | 186 | |
| | 187 | the applications which are defined in the given Emakefile(s) are loaded into the database. Please note, that |
| | 188 | * the configurations, which are defined in the Emakefile, only stored temporary, while the adding procedure has not been finished; |
| | 189 | * if the Emakefile contains relative path, then it will be converted absolute by using the path of the Emakefile as base. |
| | 190 | |
| | 191 | If your apllications have been loaded by using {{{ri:add_by_emakefile/1}}} and any of the applications uses irregular include path or compile-time macro, |
| | 192 | then these applications should be updated by using {{{ri:add_by_emakefile/1}}}, or by loading the configuration {{{ri:load_configuration/1}}} then by executing {{{ri:database_synchronization/0}}}.\\ |
| | 193 | If the loaded configuration is not needed further then it may be unloaded by executing {{{ri:unload_configuration/1}}}. |
| | 194 | |
| | 195 | Applications can be dropped from the database in the same way as the normal files. |
| | 196 | |
| | 197 | == Refreshing your database == |
| | 198 | If your files has been changed in the disk, since the last load, then these files may be re-added to the database to gather fresh information about the files from the tool. This can be easily done, by executing one of the following commands: |
| | 199 | {{{ |
| | 200 | #!erlang |
| | 201 | ri:database_synchronization(). |
| | 202 | |
| | 203 | ris:database_synchronization(). |
| | 204 | }}} |
| | 205 | |
| | 206 | == Gathering information about your database == |
| | 207 | |
| | 208 | For convenience, both the filenames and the directory names can be given |
| | 209 | as atoms as well as strings. |
| | 210 | The list of loaded files can be obtained by calling |
| | 211 | |
| | 212 | {{{ |
| | 213 | #!erlang |
| | 214 | ri:ls(). |
| | 215 | }}} |
| | 216 | |
| | 217 | This call also displays the status of the loaded files (error or no_error). |
| | 218 | If the module m is loaded, |
| | 219 | |
| | 220 | {{{ |
| | 221 | #!erlang |
| | 222 | ri:ls(m). |
| | 223 | }}} |
| | 224 | |
| | 225 | will give information about the functions, records and macros in the file. |
| | 226 | The contents of a file can be listed by |
| | 227 | |
| | 228 | {{{ |
| | 229 | #!erlang |
| | 230 | ri:cat(ModFile). |
| | 231 | }}} |
| | 232 | |
| | 233 | The content of a function can be listed by |
| | 234 | |
| | 235 | {{{ |
| | 236 | #!erlang |
| | 237 | ri:cat(ModFile, {FunName,Arity}). |
| | 238 | }}} |