

| Home |
| Highlights |
| Screenshots |
| Get GODI |
| Docs |
| Mailing List |
| Resources |
| Packages |
| Workgroups |
| OASIS |
| Why Ocaml? |
The Ocaml distribution (compilers, runtime system, tools and libraries as distributed)
A lot of libraries for O'Caml. See packages.html for a list.
Some C libraries when the packagers found it useful to include them
A small number of applications
ftp_proxy=http://proxy.company.com http_proxy=http://proxy.company.com export ftp_proxy http_proxy
SEARCH_LIBS += $d(where $d is the expanded absolute path name). The locations $d/include and $d/lib are then searched for libraries. If you need also binaries, you need to put $d/bin into PATH, of course.
Currently, GODI knows two kinds of dependencies: strict dependencies, and build dependencies. A dependency enforces that another package is installed when a package is used (strict case), or when it is built.
This sounds well-known, but note that there are subtle differences to other package managers that focus on software written in the C language. This is better explained by an example: assume there are libraries A and B, and that B depends strictly on A. It is the normal case that the dependencies between libraries are strict, because you cannot use B without A (even though O'Caml libraries are static).
The first difference is the strict version control. For example, B might demand that the version of A is at least 1.0. For C-language software, this requirement is interpreted both for the build time and for the run time of the library. This means that you can replace version 1.0 by 1.0.1 without any trouble, just install it. For O'Caml, however, this is a very rare case. The smallest change in the interfaces of libraries cause that they become incompatible, and that means that you must rebuild B if you upgrade A from 1.0 to 1.0.1. Because of this, a requirement like A>=1.0 is automatically transformed to A=1.0 (or whatever version is found) for the installed library.
The next difference is a consequence of the first: If you upgrade a library like A, you must recompile all dependent libraries like B. Because this happens frequently, GODI supports this explictly: If you select a package in godi_console for rebuild, all dependent packages are selected, too, after you have typed 's'.
Note that only strict dependencies are affected by this rule, not build dependencies.
The algorithm GODI uses for dependency analysis is quite complex, because it checks dependencies both in the direction of missing or bad requirements, and in the direction of successors that use a package.
There is a very good reason why godi_console is a text application: you don't need working graphics libraries to get GODI running. Furthermore, there are situations where a text application has advantages over a GUI application, e.g. when the network has too little bandwidth or too big latency, or when the target system does not have a working X installation (think of network servers or mobile devices).
Of course, this only explains why the text version of godi_console has higher priority than the GUI version. The design of godi_console includes the option of a later GUI version, but nobody has yet written the missing Miniui_labl(g)tk module we would need.
godi_console perform -build godi-xstrMore information can be found in manual pages, and in the GODI User's Manual.