[Monetdb-developers] configure & *_config.h include files
jens.teubner at in.tum.de
Sun Sep 24 10:48:51 CEST 2006
On Fri, Sep 22, 2006 at 02:25:21PM +0200, Stefan Manegold wrote:
> Dear fellow developers,
> while trying to fix portability issues with the pftijah modules of
> pathfinder, I noticed the following problem:
> To ensure portability, each source file should know about and adhere to what
> configure found out; hence, the respective X_config.h (with X one of
> monetdb, sql, pf, etc,) must be the first include in each .c file.
This is a longstanding problem. I actually "complained" about this more
than two years ago (see, e.g., bug #957994). On the Pathfinder side,
there is (more or less) silence since I ripped out all references to
monetdb_config.h in July 2004 (despite people telling me that that such
a reference is required and that it cannot simply be avoided :-)).
> This might trigger two problems:
> 1) If we compile sql, pf, etc, a against a binary install of MonetDB which
> was configured and generated on an binary compatible but potentially
> (slightly) differently configured/installed system, this might lead to
> conflicting definition/declarations in the two X_config.h.
> 2) Even if we compile MonetDB and the front-end on the same system, there
> might be conflicts since the respective configure are not completely
There's one more instance of this problem:
3) The user is free to use different ./configure options for MonetDB
and, e.g., Pathfinder. For instance, he/she may want to compile one
package with icc, the other one with gcc.
This definitely rules out any approach that tries to align all the
./configure scripts in any way. The same ./configure script may give
different results also depending on its options!
So this rules out a solution proposed by Stefan:
> To solve the problem (2) "properly", we could either make all
> configures identical (e.g., by moving all "local" checks from the
> various configure.ag to MonetDB/conf.monet.m4).
> But that still leaves us with (1).
But it also rules out the other solution proposed by Stefan:
> A "better"(?) (at least simpler) solution could be to guard the
> #include "monetdb_config.h" in MonetDB' monet_utils.h by, say,
> #ifndef NO_MONETDB_CONFIG ... #endif,
> and then define NO_MONETDB_CONFIG in X_config.h (with X one of sql, pf,
This would mean that MonetDB was compiled with some option. Then, e.g.,
Pathfinder is linked against MonetDB under the assumption that MonetDB
uses some some different options.
So the problem is definitely not a trivial one. Let me throw in some
The only thing we need to access from some MonetDB add-on (e.g.,
Pathfinder) are its *interfaces* to specific functionality. So the
first question is: Must these interfaces be dependent on the outcome of
./configure (that is, are there any type declarations, function
declarations, etc. in the *interfaces* from an add-on to MonetDB that
depend on ./configure?). If they aren't, we should factor out stable
interfaces (that are independent of the ./configure run and, hence,
don't include monetdb_config.h) and only reference those from outside.
If they *are* dependent, we may still take the same road and *generate*
interfaces (i.e., include files) when compiling MonetDB that only depend
on the ./configure outcome once (during generation). I'm thinking of a
file that only contains
typeA_t foo (...)
typeA_t foo (...)
typeB_t foo (...)
These ideas pretty much go into the direction of this proposal of
> To solve (1) (and (2)) "properly", we could avoid the implicit
> inclusion of monetdb_config.h in monet_utils.h (and hence gdk.h &
> monet.h) by removing the respective include from monet_utils.h.
> But then, we'd have to explicitly include monetdb_config.h in each .c
> file that now includes one of monet_utils.h, gdk.h, monet.h (directly
> or via some other include) --- a lot of work, with a high risk to
> overlook some locations...
So these are my comments, ideas, complaints, objections. :-)
Technische Universitaet Muenchen, Department of Informatics
D-85748 Garching, Germany
Tel: +49 89 289-17259 Fax: +49 89 289-17263
-- `perlstyle' man page
More information about the developers-list