[Monetdb-developers] IMPORTANT: imminent change to repositories

22 Dec 2006

      This is a heads up.  Read this.  It affects all developers (however,
developers only fixing bugs on the stable branch can postpone reading this).

MonetDB Repository Split Into Three

This whole story *only* affects the CURRENT branch, the STABLE branch is
totally unaffected by the changes described here.

This change is *imminent*.  It will probably happen today.  There will
be CVS tags before and after.

The MonetDB repository will be split into three repositories.  One
repository will contain the fundamentals of MonetDB (GDK) and other
common stuff that is used by all other subprojects (src/common).  This
repository remains called MonetDB.  Another repository will be clients.
This repository contains all client libraries and programs.  It is
independent from the GDK part of MonetDB, but it does depend on the
common libraries.  The final repository will be MonetDB4 which contains
the MIL-specific part of the old MonetDB repository.

The new layout of the MonetDB family is the following repositories:
- buildtools contains the stuff that is needed to compile any of the
following from CVS;
- MonetDB containing GDK and common, i.e. stuff that forms the core of
the MonetDB family and stuff that is generally useful (src/common);
- clients contains libraries and programs that connect to the various
servers, i.e. the Mapi library (in several languages), ODBC, JDBC.
- MonetDB4 contains the MonetDB4-specific parts, i.e. stuff like the MIL
parser and execution engine (src/monet), and the MonetDB4 modules;
- MonetDB5 (still at CWI repository as monet5, to be moved to
SourceForge "soon") contains the MonetDB5-specific parts, i.e. stuff
like the MAL parser and execution engine and the MonetDB5 modules;
- sql contains the SQL frontend;
- pathfinder contains the XQuery frontend.

And then there are of course the other repositories amdb, xml, template,
etc.

Dependencies

This is written in the suggested order of compilation and installation.

When compiling from CVS, you always need buildtools, and this needs to
be compiled and installed first.

MonetDB does not depend on anything else.

clients depends on MonetDB (specifically on src/common).

MonetDB4 depends on MonetDB and clients.  It depends on clients only for
the embedded library and programs using that library.

MonetDB5 depends on MonetDB and clients (and *not* on MonetDB4).  It
depends on clients only for the embedded library and programs using that
library.

sql depends on MonetDB, clients, and MonetDB4; but if you want MonetDB5
support, also on MonetDB5 (the dependency should become: at least one of
MonetDB4 and MonetDB5, i.e. either one or both backends).

pathfinder depends on MonetDB, clients, and MonetDB4; but if you want
MonetDB5 support, also on MonetDB5 (the dependency should become: at
least one of MonetDB4 and MonetDB5, but the port to MonetDB5 needs to be
finished first...).

Other Changes

The scripts bootstrap, de-bootstrap, and conf/conf.bash have been moved
to the buildtools repository.  Replacement scripts have been put in
place that use the scripts that get installed when buildtools is installed.

A C source file should now include the project's own config.h file (i.e.
pf_config.h for pathfinder, mal_config.h for MonetDB5, etc.) as the
first include in the C file.  The config.h file should not be included
in H files that get installed and used by other projects.  In
particular, gdk.h and monet_utils.h now no longer include monetdb_config.h.

A project's configure script now has to perform all the configure tests
that are needed for .h files that are included from other projects.
Most of the required tests for the stuff in MonetDB are now done in the
call to AM_MONETDB_COMMON (if any are missing, that is a (lowish
priority) bug and should be fixed).

Future Changes

The changes described here have not happened.  They are thoughts for
future work.

More configure and header file cleanup.  In an ideal world, we have
header files that are used externally which do not contain and #ifdef
HAVE_* sections, and header files that are used internally that can
contain such sections.  Also, it should be possible to figure out at
configure time from the already installed parts either the correct
options (such as how wide the OID type is), or that the given options
are not compatible with the installed parts (and give a configure
error).  Currently it is the developer's responsibility to make sure
that configure options are compatible.

-- 
Sjoerd Mullender

Sjoerd Mullender

Arjen P. de Vries

Stefan Manegold

Arjen P. de Vries

Stefan Manegold

Arjen P. de Vries

tags

participants (3)