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 identical.
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, etc,).
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 thoughts: 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 (...) and not #if HAVE_FOO typeA_t foo (...) #else typeB_t foo (...) #endif These ideas pretty much go into the direction of this proposal of Stefan:
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. :-) Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 Be consistent. -- `perlstyle' man page