Search GODI:
====================================================================== Frequently Answered Questions on GODI ====================================================================== Note: This is the beginnning of a FAQ page, in order to make information more accessible. It is based on real questions. ---------------------------------------------------------------------- Why are POSIX threads disabled for FreeBSD? ---------------------------------------------------------------------- Because they don't work well enough, i.e. there is a problem in the threading implementation of FreeBSD. For a description of the problem, see tickets 1820, 1821 of the O'Caml bug database: http://caml.inria.fr/bin/caml-bugs/not%20a%20bug?id=1820;page=47;user=guest http://caml.inria.fr/bin/caml-bugs/not%20a%20bug?id=1821;page=48;user=guest ---------------------------------------------------------------------- GODI does not work on Gentoo. What is going on? ---------------------------------------------------------------------- > Thank you for your answer.You were right, I had > the environment variables PKGDIR and DISTDIR > set, and this was messing up with the installation of Godi. > This is quite puzzling, and those variables are often > set when using a Gentoo Linux distribution ... Perhaps > it would be a good idea to unset them in Godi scripts. It is a bug that these variables are taken from the environment. ---------------------------------------------------------------------- Scanning the packages takes so long. Why? ---------------------------------------------------------------------- > I like Godi a lot, it seems quite powerful. But if think > it's strange that with only 34 packages, the scanning > takes several seconds ... Because it invokes "make" 34 times. I am already working on a solution, a Makefile parser. The problem is that "make" does 34 times almost the same (parsing some large files), and with an integrated parser I can arrange that the expensive, repeated actions are done only once. ---------------------------------------------------------------------- How do I make a GODI package? ---------------------------------------------------------------------- (Removed - this is now explained in the "GODI User's Manual".) ---------------------------------------------------------------------- For some libraries there are three packages: base-foo, conf-foo, godi-foo. Why? ---------------------------------------------------------------------- Background information: The base-foo package contains the C library, and is optional (it is also possible to use an already installed version of the C library). The conf-foo package contains compiler and linker options for this library. The godi-foo package is the rest, i.e. the O'Caml bindings, and the higher layers. > What is the rationale behind the three packages approach? Wouldn't it be > possible to have a single package that takes care of installing the C > library if necessary (maybe by creating dynamically a virtual local > package)? I doesn't know much about the BSD package system, so this may > simply be stupid. There is no such thing like a virtual package: Every source package produces exactly one binary package. So the base package must be an extra package (which, btw, has also the advantage that we can copy it from NetBSD). There are several justifications for the conf package: - Library sharing: It is possible that several O'Caml packages implement bindings for the same C library (e.g. libX11 is already used by a lot of packages). The code for determining the compiler options must only be written once, and it is ensured that all users of a library use the same instance - Easier configuration: The conf package quickly determines whether the compiler options do work or do not work. If this kind of configuration were integrated into the configuration step of the godi-xxx package, it would take longer, and the relevant messages would be only a fraction of the whole output. (However, this may be different in the concrete case.) - Documentation: The "binary" conf package contains the conf-xxx.mk file that documents which library instance was really used when the package was built. This can be quite important information when you want to maintain systems over a longer period of time. Note that there are some packages that do NOT follow the three-package approach, e.g. godi-lablgl. They still use the old style, and need to be updated. Please do NOT put the file godi.pkg.defaults.pat into your build directory; this feature will be removed. So, how do conf packages work? For instance, conf-pcre is a good example. When you build conf-pcre, you can pass a number of options to it: - GODI_BASEPKG_PCRE (whether to link against the library in base-pcre) - GODI_PCRE_INCDIR (directory where to find include files) - GODI_PCRE_LIBDIR (directory where to find the library file) This is purely optional. If these options are missing, it will be tried to guess them (like autoconf would do it). The build will fail if the options cannot be figured out. It is even tried to compile test programs linking with libpcre to be absolutely sure that the options work. The result of the build stage of conf-pcre is a single file: lib/godi/conf-pcre.mk. It contains four variables which are now ensured to contain working settings: - CONF_PCRE_INCDIR (directory where to find include files) - CONF_PCRE_LIBDIR (directory where to find the library file) - CONF_PCRE_NEED_RPATH (whether to pass -rpath to the linker) - CONF_PCRE_DEPENDS (additional package dependencies to get pcre) A package that wishes to link against libpcre can now include this file into its own Makefile, and can directly use these variables. Because conf-pcre has generated them, it is guaranteed that they work. See godi-pcre for an example. When CONF_PCRE_DEPENDS is non-empty, it contains the dependeny on base-pcre, i.e. one can simply add this variable to DEPENDS. Note that the CONF_* variables must not be set in godi.conf. They are not intended to be configurable by the user. The corresponding GODI_* variables should be set by the user. Note that there is the global variable SEARCH_LIBS that contains directories where the configure script should search libraries. By default, a number of frequent locations are tried, like /usr, /usr/local, /usr/pkg. One can set SEARCH_LIBS in godi.conf to add more directories. ---------------------------------------------------------------------- The C library provides a "foo-config" script printing compiler and linker options. Should I use this script for my package? ---------------------------------------------------------------------- [Answer updated on 2004-02-27.] > I was concerned about the lack of support for curl-config (a shell script > that can provide relevant compiler flags for the library). Instead of > having GODI_CURL_INCDIR and GODI_CURL_LIBDIR, it would be possible to have > a single GODI_CURL_CONFIG pointing to the curl-config shell. Actually, the > same applies to pcre. Any opinion about these xxx-config? These scripts follow a quite simple philosophy, and work very well if you have only one (system) instance of the library. If there is more than one instance, the PATH variable will control which of the instances is actually used. You can get into difficult situations when there are several libraries, and for some of them the system version should be preferred, and for some of them another version. Which PATH is the right one? I think there should be the option of detailed control where the library is expected to reside. This means it should be at least possible to specify the exact path of the foo-config script. We have already packages that rely on pkg-config, among them is lablgtk2. It currently does not allow to detail from which script it extracts its configuration. This is something to improve, and should not be copied for other packages. Of course, only using the system instance makes sense here (in other words: supporting alternative library instances would mean a lot of work with questionable value). A very good example how to take advantage from foo-config scripts are the packages conf-sdl and godi-ocamlsdl. The library SDL always installs an sdl-config script. The package conf-sdl searches this script in PATH, but it is also possible to specify the exact location. Furthermore, it is tested whether the configuration works, and it is also tested whether RPATH options must be added. It is, however, not possible to specify the compiler and linker options for SDL manually. In godi-ocamlsdl it must be ensured that the tested sdl-config script is actually used for configuration. Fortunately, this location of this script can be passed to the "configure" script of ocamlsdl (as environment variable). The advantages of this solution: - It is still possible to have SDL installed in unusual locations, it is not even necessary to have sdl-config in PATH. - After the package conf-sdl is installed, the configuration is fixed, and is no longer depends on environment variables like PATH. This means the configuration is reproducible. - The package conf-sdl does not blindly trust the script sdl-config. It is tested whether the configuration works before it is accepted for the inclusion into the GODI installation. ---------------------------------------------------------------------- It is possible to have more than one instance of GODI? ---------------------------------------------------------------------- Of course, but you must bootstrap GODI several times into distinct target directories. > 6) It appears that gobi only supports one instance of ocaml. Can > it support more than one and be like a general RPM database > that supports multiple versions? > > I can see this being hard to do and not worth the effort. > However, I may want multiple Ocaml installs to support > products and people with older Ocaml's. In this case, > even if I couldn't share godi, it would be useful to have > a common build directory. Is this possible? You can have several independent godi installations. I think this is the only sensible way to handle this problem. Maybe there should be better support for transferring package lists from one instance to the other, so one can create easily a new godi installation with the same packages (but different versions) and configuration as an already existing installation. Supporting multiple versions with one installation is almost impossible. In my first trial I had a tricky directory layout such that there would be several ocaml versions, and one could switch between them. I dropped that because it was not worth the effort, too error-prone, and there is also the problem that godi itself depends on one version of ocaml, and the question is on which version. Sharing build directories: No good idea. You can share the "distfiles" directory, but I think all other directories could be problematic, especially "packages" (because the requirements of a package are not encoded in the filename). "mk" is an essential part of godi. The other directories are only temporarily used, so sharing them is not very advantegous. ---------------------------------------------------------------------- Why does GODI use the RPATH feature to look up shared libraries? ---------------------------------------------------------------------- Background information: GODI patches the ocamlmklib script such that stub libraries dllfoo.so always look into the lib directory of GODI, where additional shared libraries can be installed. The real question here is whether it is possible to get rid of this patch. > What about LD_LIBRARY_PATH? I believe that in general it overrides the > search path of the binary, and people often set it to /usr/local/lib > on solaris... I know a lot of people who consider LD_LIBRARY_PATH as an unprofessional solution, at least for a permanent installation. The point is that the caller of a program must ensure that libraries are found, and not the program itself. A lot of things can go wrong. setuid programs do not work. It is sometimes difficult to set LD_LIBRARY_PATH, e.g. for programs called from daemons. Administrators don't like it because it is another global thing they have to manage. Btw, Solaris has now something like ld.so.conf of Linux, but it is called differently, and adding a directory here is a good idea if it should be considered as equal with /usr/lib. However, this is no solution for GODI's lib directory. This is not a global directory, it should be possible to have several GODI installations on the same system. ld.so.conf is no option. LD_LIBRARY_PATH has disadvantages and acceptance problems. I think the only remaining possibility is to set the RPATH section in the executables (which is supported by all ELF systems, and maybe others). I have done this by patching ocamlmklib (but it could also be a wrapper around ocamlmklib to get rid of the patch).
