I think the ideal solution to the problems would be something along the lines of this: Projects that use MonetDB should not depend on monetdb_config.h, but instead in their own configure step figure out what the relevant parameters are with which MonetDB was compiled. This means that there should be a way for those configure scripts to figure this information out, possibly be including monetdb_config.h in a configure test. We can still have these other projects share the code base for configure (i.e. MonetDB's conf/monet.m4), but they should not use the output of a different run of that code base. This solution involves figuring out *all* the relevant parameters. I can think of some off-hand (sizeof(long), sizeof(oid)), but there may be more. On 2006-09-24 21:31, Fabian Groffen wrote:
This post is OT, but I felt the need to formulate an answer.
On 24-09-2006 21:01:30 +0200, Jens Teubner wrote:
On Sun, Sep 24, 2006 at 03:04:55PM +0200, Fabian Groffen wrote:
... or make it easier for users and yourself and make it all one package, where you just do --{enable,disable}-{sql,xquery,...} at the configure call. Greatly eases packaging too. No.
We simply disagree. Not only we. But then again, I'm not even surprised anymore when people can't get MonetDB to do something useful, let alone just use it, because people seem to "on purpose" make it as hard as possible to make the system usable from a normal user perspective.
No pun intended. This is not a personal remark.
It's just weird that it can be partly done for windows users, but not for a much bigger group of our users.
-- I want to spend my development time with programming and *not* with compiling MonetDB over and over, just because there have been other
As long as other people commit to your code, this will always be the case, no matter how large or small.
-- Pathfinder is a standalone and retargetable compiler. Most of my
The part of pathfinder that makes MonetDB/XQuery is a piece that should be easily obtainable and usable, to make the pathfinder sources as useful as possible to people who are not experienced developers.
Throwing all our code into a single big pot would only heal the single symptom that we are currently observing. Even worse, it would lead to a bigger mess in our code, instead of enforcing discipline and stable, well-designed interfaces.
Good API/interfacing doesn't seem to be much related to where the code is located, but more to who is writing it, IMHO.
Other open source projects, by the way, have had to spend a lot of effort to go just the opposite way, from a bloated monolithic project to a nice, modularized software (I'm thinking of the XFree project here).
(Modular) XOrg is a couple of times bigger than MonetDB. Sure, I've nothing against modularising of code. But it should not harm the usability of the code. With MonetDB, it is clear to me that the current setup greatly harms the general usability of the software, and results in all kinds of insane decisions (e.g. MapiClient supports all languages and has semantic knowledge on those, while Mserver doesn't know anything and needs to be instructed using a sequence of commands in order to let it use such language.).
I believe that for MonetDB's existance in the database world it would be good if people (devs) would see the product as a whole. Ok, I admit immediately, that has close to nothing to do with research.
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
-- Sjoerd Mullender