Is there anyone that can think of a solution for this problem?
cc1: warnings being treated as errors
/Volumes/Scratch/monetdb/stable/monetdb/src/modules/plain/bat.mx: In function 'local_itoa':
/Volumes/Scratch/monetdb/stable/monetdb/src/modules/plain/bat.mx:1253: warning: format '%zd' expects type 'signed size_t', but argument 4 has type 'ssize_t'
I mean... is there a difference between "signed size_t" and "ssize_t"?
Ehrm.
[Orion:src/modules/plain] fabian% uname -a
Darwin Orion.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc PowerBook4,3 Darwin
[Orion:src/modules/plain] fabian% gcc --version
gcc (GCC) 4.0.1 (Apple Computer, Inc. build 5341)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Probably just need to compile without -Werror.
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
Stefan Manegold wrote:
> Update of /cvsroot/monetdb/sql/NT
> In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv13165/NT
>
> Modified Files:
> configure.py rules.msc
> Log Message:
>
> cleaning-up & preparing the "monet5" to "MonetDB5" move:
>
> - renamed all remaining MONET5_* (enironnment-) variables to MONETDB5_*
> - renamed all remaining *_monet5 aliases to *_MonetDB5
>
> In case you use any MONET5_* (enironnment-) variables or
> *_monet5 aliases in your own scripts,
> you need to rename them to MONETDB5_* respectively *_MonetDB5,
> too.
Oops, it seems you have been out of the loop or overwhelmed with
emails regarding the BIG BANG cleanup.
I already mentioned to sjoerd/niels/fabian/... that the naming
of packages should be given some thought and discussed.
- move the package names to lower-case instead of a mixture of upper/lower
- suggested packages names (if feasible on SF), buildtools,gdkcommon, clients,
monet4, monet5, sql, and pathfinder.
This propably won't affect your Environment variables.
Dear developers,
I am using the following configure for M4:
env
PATH=/ufs/goncalve/scratch/MonetDB/buildtools/bin:/ufs/goncalve/scratch/MonetDB/clients:/ufs/goncalve/scratch/MonetDB/MonetDB/bin:${PATH}
PYTHONPATH=/ufs/goncalve/MonetDB/buildtools/autogen/
~/MonetDB/MonetDB4/MonetDB4/configure
--prefix=/ufs/goncalve/scratch/MonetDB/monetdb4 --enable-debug
--enable-bits=64
However, the compilation gave this error:
-c embeddedclient.c -fPIC -DPIC -o
.libs/libembeddedmil_la-embeddedclient.o
In file included from
/ufs/goncalve/MonetDB/MonetDB4/MonetDB4/src/tools/embeddedclient.mx:69:
embeddedclient.h:29:18: error: Mapi.h: No such file or directory
I already add to the PATH the prefix for the clients installation.
What more I need to add to the path?
Why the configure of M4 does not complain about such missing?
Regards,
Romulo
I'm trying to bootstrap buildtools but foud out that buildtools is
shipped with an configure.ac which isn't an ac file, but just plain
configure itself (as the local bootstrap script just copies it to
configure). This is hard to detect for my generic scripts who like to
generate a configure from the .ac file. Is there a reason why this ac
file exists? If not, I'd be happier if it could just be renamed to
configure instead, as I don't think this is the right solution.
I advice you to fix it properly, because your hack doesn't result in the
desired effect.
1) create_mjclient will build the jdbcclient.jar when it's not there,
and it will end up in the builddir (where you don't want it)
2) if it wouldn't do that, it would think that the jdbcclient.jar file
is located in the builddir, because you just told it so, hence rhe
resulting script won't work.
On 27-12-2006 15:29:28 +0000, Niels Nes wrote:
> Index: build.xml
> ===================================================================
> RCS file: /cvsroot/monetdb/clients/src/java/build.xml,v
> retrieving revision 1.4
> retrieving revision 1.5
> diff -u -d -r1.4 -r1.5
> --- build.xml 27 Dec 2006 14:54:22 -0000 1.4
> +++ build.xml 27 Dec 2006 15:29:26 -0000 1.5
> @@ -120,12 +120,10 @@
> <echo message="Crafting an mjclient wrapper script for ${jdbcclient-jar}" />
> <filter token="JDBCCLIENT_JAR" value="${jdbcclient-jar}" />
>
> - <!-- create bindir -->
> - <mkdir dir="${bindir}" />
> <!-- now copy and filter the file -->
> <copy file="${scriptdir}/mjclient.in"
> overwrite="true"
> - tofile="${bindir}/mjclient"
> + tofile="${builddir}/mjclient"
> filtering="yes" />
> </target>
On 12/27/2006 03:30 PM, Fabian wrote:
> Update of /cvsroot/monetdb/buildtools
> In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv5580
>
> Modified Files:
> Makefile.in
> Log Message:
> Force python to respect the build dir, as it pollutes the source dir
> otherwise. This is extra annoying because when using different
> platforms from the same source tree, python thinks its build cache is
> fine, and just installs files which plain won't work on the target
> machine.
This I don't quite understand. Autogen is python only. There are no
platform-dependent files there at all. So, what is the problem that
you're fixing?
(This is not saying that I mind the solution, I question the reason.)
>
> Index: Makefile.in
> ===================================================================
> RCS file: /cvsroot/monetdb/buildtools/Makefile.in,v
> retrieving revision 1.6
> retrieving revision 1.7
> diff -u -d -r1.6 -r1.7
> --- Makefile.in 22 Dec 2006 15:42:21 -0000 1.6
> +++ Makefile.in 27 Dec 2006 14:30:46 -0000 1.7
> @@ -10,14 +10,17 @@
> @-echo
>
> all:
> - cd "$(SRC)/autogen" && python setup.py build
> + cd "$(SRC)"/autogen && python setup.py build \
> + --build-base="$(BUILD)"/_autogen
> cd _MX && $(MAKE) MAKE=$(MAKE) $@
> cd _MEL && $(MAKE) MAKE=$(MAKE) $@
> cd _BURG && $(MAKE) MAKE=$(MAKE) $@
>
> # ... run individual "make install"s ...
> install:
> - cd "$(SRC)/autogen" && python setup.py install --prefix="$(DESTDIR)$(PREFIX)"
> + cd "$(SRC)"/autogen && python setup.py install \
> + --build-base="$(BUILD)"/_autogen \
> + --prefix="$(DESTDIR)$(PREFIX)"
> cd _MX && $(MAKE) MAKE=$(MAKE) $@
> cd _MEL && $(MAKE) MAKE=$(MAKE) $@
> cd _BURG && $(MAKE) MAKE=$(MAKE) $@
>
>
> -------------------------------------------------------------------------
> 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-checkins mailing list
> Monetdb-checkins(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/monetdb-checkins
--
Sjoerd Mullender
Hi all,
yesterday I updated buildtools, MonetDB and I checked out the MonetDB4
module. buildtools and MonetDB working fine after i updated autoconf and
automake to the newest versions but with MonetDB4 i get the errors
described in the attachment.
Regards,
Manuel
Dear developers,
I am updating all my system in linux with the new splits over MonetDB4.
I checkout the MonetDB module (and not MonetDB4) ;)
The execution of ./bootstrap gave this error:
[goncalve@amelia MonetDB]$ ./bootstrap
./bootstrap: line 32: exec: Mbootstrap: not found
[goncalve@amelia MonetDB]$
Any idea?
Regards,
Romulo
Dear Sir/Madam:
I came across a problem when running a SQL statement:
select l_linestatus
from lineitem
where shipdate <= date '1998-12-01' - interval '1 day' //I want to
search the records whose shipdate is prior to the day before Dec. 1998
But MonetDB returned me with the error message: syntax error, unexpected
SCOLON in: "select ...," the whole SQL sentence above,
What's wrong?
Thank you!
eric
--
View this message in context: http://www.nabble.com/About-data-type-%22interval%22-tf2869866.html#a8021165
Sent from the monetdb-developers mailing list archive at Nabble.com.