/usr/share/doc/libfindlib-ocaml-dev/guide-html/c37.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Libraries and Packages</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REL="HOME"
TITLE="The findlib User's Guide"
HREF="index.html"><LINK
REL="UP"
TITLE="User's Guide"
HREF="p35.html"><LINK
REL="PREVIOUS"
TITLE="User's Guide"
HREF="p35.html"><LINK
REL="NEXT"
TITLE="Using packages"
HREF="c74.html"></HEAD
><BODY
CLASS="CHAPTER"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>The findlib User's Guide</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="p35.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="c74.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="CHAPTER"
><H1
><A
NAME="AEN37"
></A
>Chapter 1. Libraries and Packages</H1
><P
> Reusability is one of the keywords in software engineering
today. It simply means to have source code that can be shared by
several programs. Usually, modules are combined to libraries, and the
library archive files can be linked into programs. As the idea might
be simple, its practical implementation is complex because sharing of
source code has an impact on all steps and phases in software
production. This document only addresses the following administrative
problems:</P
><P
></P
><UL
COMPACT="COMPACT"
><LI
STYLE="list-style-type: disc"
><P
>Storing the libraries in file hierarchies</P
></LI
><LI
STYLE="list-style-type: disc"
><P
>Compiling and linking programs using such libraries</P
></LI
><LI
STYLE="list-style-type: disc"
><P
>Managing dependencies between libraries</P
></LI
></UL
><P
>Objective Caml has a variety of language means to support
reusability. Most important, polymorphic functions can be written
which generalize the types of input arguments and the
type of the result value. There are many examples in the core library
such that I assume that the reader is familiar with this
feature. Second, modules and functors must be mentioned which not only
generalize types of values, but can even generalize structures,
i.e. types with associated operations. Third, the class construct
allows us to adopt the object-oriented techniques of abstraction such
as inheritage and dynamic method lookup.</P
><P
>In the following, we are only analyzing the problem of making and
using libraries from a purely software-technical point of view. This
means, we ignore how to make functions polymorphic, and how to create
functors and classes. Instead, we only look at how to invoke the
O'Caml compiler to create, manage, and use libraries. Especially, we
are interested in the administration of systems of libraries that
have dependencies.</P
><P
>One of the complex operations on such a system is the replacement of 
a library by a newer version. Because of the strict compatibility
checks of O'Caml, it is usually necessary to rebuild and reinstall
all dependent libraries as well. With the help of findlib, one can
find out which are the dependent libraries. (However, findlib does
not provide a framework to rebuild them. For example, the GODI
system includes such a framework.)</P
><P
>The library is also called a "package" when it is seen as a removeable
and replaceable set of files. Findlib requires that there is a 
certain directory structure; it is not possible to install the files
at arbitrary places (findlib does not even maintain a file list).
For simplicity, every library is usually stored into its own
directory, i.e. the library archive files and the interface files.</P
><P
>From the perspective of the compiler, the library is made
accessible by adding the package directory to the search path
of the compiler. By doing so, the modules of the library are
added to the namespace universe, and thus can be opened by 
modules using them. This means that the approach "one package
= one directory" can be naturally translated into language
operations modifying the namespace scope.</P
><P
>When linking a program, it must be specified which link operation is
necessary to use a certain library. Often, only a single archive file
needs to be linked in, but sometimes additional archives or system
libraries must be linked, too. Furthermore, the link operations
often depends on certain conditions, e.g. whether a single- or
multi-threaded program is being created.</P
><P
>The <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>findlib</I
></SPAN
> library is my suggestion for a
package manager suitable for Objective Caml. It is a library (stored
as a package itself) which can answer the following questions:</P
><P
></P
><UL
COMPACT="COMPACT"
><LI
STYLE="list-style-type: disc"
><P
>If I want to use a package, which is the directory containing
the compiled interfaces and implementations? - The package directory
may vary from system to system, and this feature makes it easier to
write Makefiles that run everywhere. Furthermore, OCaml can load
modules dynamically, and it is not a good practice to compile in the
location of such modules. The better way is to ask findlib where the
module resides today.</P
></LI
><LI
STYLE="list-style-type: disc"
><P
>Which other packages must be linked in, too, if I want to use a
certain package?</P
></LI
><LI
STYLE="list-style-type: disc"
><P
>Which archives need to be linked in, and which compiler options
are necessary?</P
></LI
><LI
STYLE="list-style-type: disc"
><P
>If there is a version of the archive with additional properties,
which file should I use? - Additional properties are at least:
Thread-safety, using POSIX threads, and being gprof-enabled. It is
simple to add more criterions.</P
></LI
></UL
><P
>Furthermore, there is a frontend for this library called
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>ocamlfind</I
></SPAN
>. It is a command-line interface for the
library, but has also some additional abilities:</P
><P
></P
><UL
COMPACT="COMPACT"
><LI
STYLE="list-style-type: disc"
><P
>It can invoke ocamlc, ocamlopt, ocamlmktop, and ocamlcp such
that compiler arguments necessary to use a package or link it in are
automatically added.</P
></LI
><LI
STYLE="list-style-type: disc"
><P
>It can install and uninstall packages.</P
></LI
><LI
STYLE="list-style-type: disc"
><P
>It can find out dependent packages.</P
></LI
></UL
><P
>As you'll see in the following chapters, the usage of this library is
really simple. If you want only to link in packages written by other
people, you must only change the command that invokes the compiler,
e.g. instead of calling "ocamlc program.ml" invoke "ocamlfind ocamlc
-package name_of_package_to_use -linkpkg program.ml", and you can
refer to the named package within program.ml. If you want to turn your
collection of modules into a package, you need only to write one
adminstrative file (META) containing all extra information such as
required other packages.</P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="p35.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="c74.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>User's Guide</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="p35.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Using packages</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
libfindlib-ocaml-dev 1.5.5-2build1 / usr / share / doc / libfindlib-ocaml-dev / guide-html / c37.html
