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.