Hello Stefan (and Djoerd), My apologies for having missed the HowToStart, I used the directives on the dbappl site. (http://dbappl.cs.utwente.nl/pftijah) In regards to your question about which version I used, I took the XQuery_0-20 revision from the CVS. (As indicated on http://dbappl.cs.utwente.nl/pftijah/Documentation/InstallFromCVS) After the ./bootstrap and ./configure --prefix=/usr/local/pftijah --enable-pftijah=yes, when you try to compile the whole bunch, gmake returns an error (sorry, no copy paste available) which states that it cannot the files parser.tab.h /parser.tab.c. These files are supposed to be located in pathfinder/compiler/parser/. I copied those files and it resulted in the next error, namely with nexi.tab.h and nexi.tab.c (in the pftijah module directory) (Note: I retrieved the file from the MonetDB-Mars-SuperBall tar from http://www.monetdb.nl/projects/monetdb/Download/index.html) After the copying of just those 4 files, it worked like a charm. I think the word 'generation' was not entirely correct. I had the feeling these files were created at bootstrap/configure phase(, however looking at the contents of the files, I will withdraw that feeling :)). I am no FreeBSD expert, but I'm more than positive that these 4 files are not in the cvs. With kind regards, Tristan Pothoven Stefan Manegold wrote:

On Fri, Dec 07, 2007 at 10:29:07PM +0100, Djoerd Hiemstra wrote:

...

Here are some remarks from Tristan Pothoven here in Twente for installing the stable MonetDB/XQuery on FreeBSD (FreeBSD 6.2-RELEASE-p7). He did the following: 1. 'make' on FreeBSD cannot cope with the wildcards in some of the Makefiles. No problem if you use gmake instead.

yes, we do require GNU make ('gmake') as documented in (a.o.) MonetDB/HowToStart.rst MonetDB4/HowToStart MonetDB5/HowToStart buildtools/README http://monetdb.cvs.sourceforge.net/*checkout*/monetdb/MonetDB4/HowToStart http://monetdb.cvs.sourceforge.net/*checkout*/monetdb/MonetDB5/HowToStart http://monetdb.cvs.sourceforge.net/*checkout*/monetdb/MonetDB/HowToStart.rst http://monetdb.cvs.sourceforge.net/*checkout*/monetdb/buildtools/README

...

2. Changes in sourcefiles: Package MonetDB: file: monet_utils.h original: #if HAVE_ALLOCA_H changed to: #ifdef HAVE_ALLOCA_H Package Pathfinder: file: pathfinder.h original: #if HAVE_ALLOCA_H changed to: #ifdef HAVE_ALLOCA_H

Thanks! We'll look into this.

...

3. Furthermore, it seems that the files parser.tab.h and parser.tab.c, are not generated (are they generated?) correctly. Tristan took them from the tarball on the monetdb cwi site. Similarly, in the pftijah module with nexi.tab.c and nexi.tab.h.

Hm, what does "not generated" mean --- which source did you (or Tristan) start with (CVS check out or tarball; which version) and hoe did you (or Tristan) compile them? As far as I'm aware, all files are either in the source or generated during the build process; if that's not the case, it's a bug --- but to locate and fix it we need some more specific info about what you starting point is/was and what you do/did to compile MonetDB --- "doesn't work" / "files are missing" does not help us very much ...

Stefan

...

Best, Djoerd.

-------- Original Message -------- Subject: * Re: [IR] Vraag met betrekking tot PFTijah / MonetDB Date: Fri, 23 Nov 2007 17:06:05 +0100 From: Tristan Pothoven To: Djoerd Hiemstra CC: Vliet,W.M.van(stud-INF)

Hallo Djoerd (en Marijn, de jongen van de grote xml),

Over de installatie van de stable release (zoals op de dbapps site, onder CVS) op FreeBSD (FreeBSD 6.2-RELEASE-p7) heb ik het volgende te melden:

Je moet per definitie gmake gebruiken ipv make. De make op FreeBSD kan niet overweg met de wildcards die in sommige Makefile's staan. Gmake kan dit wel.

Wijzigingen in de sourcefiles: Package MonetDB: file: monet_utils.h origineel: #if HAVE_ALLOCA_H vervanging: #ifdef HAVE_ALLOCA_H

Package Pathfinder: file: pathfinder.h origineel: #if HAVE_ALLOCA_H vervanging: #ifdef HAVE_ALLOCA_H

Verder heb ik geen wijzigingen in de code moeten aanbrengen.

Wel misten er nog wat files in de pathfinder module. Ergens in de parser (vergeef me dat ik de exacte locatie niet meer weet) missen de files parser.tab.h en parser.tab.c, deze heb ik gehaald uit de tarball beschikbaar op de monetdb cwi site.

In de pftijah module missen nexi.tab.c en nexi.tab.h. (Op dezelfde manier achterhaald en gekopieerd).

Ik geef toe, het was nachtwerk voor mij, dus mogelijke fouten die ik per ongeluk verzonnen heb: mijn excuses daarvoor, maar iig doet hij het nu. :)

Groeten,

Tristan

------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers

Hi Stefan, The site: http://dbappl.cs.utwente.nl/pftijah contains all PF/Tijah specific documentation for MonetDB/XQuery and some general guidelines on using and installing MonetDB/XQuery. I have updated it following your and Tristan's suggestions. Thanks, Djoerd. Stefan Manegold wrote:

On Sun, Dec 09, 2007 at 10:41:58AM +0100, Tristan Pothoven wrote:

...

Hello Stefan (and Djoerd),

My apologies for having missed the HowToStart, I used the directives on the dbappl site. (http://dbappl.cs.utwente.nl/pftijah)

Ok. Then, the maintainer(s) of that site might want to update the(ir) make documentation/instructions accordingly ;-)

(I actally did not know about http://dbappl.cs.utwente.nl/pftijah at all.)

...

In regards to your question about which version I used, I took the XQuery_0-20 revision from the CVS. (As indicated on http://dbappl.cs.utwente.nl/pftijah/Documentation/InstallFromCVS)

After the ./bootstrap and ./configure --prefix=/usr/local/pftijah --enable-pftijah=yes, when you try to compile the whole bunch, gmake returns an error (sorry, no copy paste available) which states that it cannot the files parser.tab.h /parser.tab.c. These files are supposed to be located in pathfinder/compiler/parser/. I copied those files and it resulted in the next error, namely with nexi.tab.h and nexi.tab.c (in the pftijah module directory) (Note: I retrieved the file from the MonetDB-Mars-SuperBall tar from http://www.monetdb.nl/projects/monetdb/Download/index.html)

After the copying of just those 4 files, it worked like a charm. I think the word 'generation' was not entirely correct. I had the feeling these files were created at bootstrap/configure phase(, however looking at the contents of the files, I will withdraw that feeling :)).

I am no FreeBSD expert, but I'm more than positive that these 4 files are not in the cvs.

The *.tab.[hc] files are generated during make (from CVS sources) by (f)lex & yacc/bison from the respective *.[yl] files --- possibly, configure could not find suitable versions of (f)lex and/or yacc/bison on your systems. Please check your configure's console output and/or config.log. We'll need to check why we do not abandon compilation (from CVS sources) in case no suitable versions of (f)lex and/or yacc/bison are found. Compiling from the source tarball does not require (f)lex & yacc/bison (or any other code-generating tools) as all extraxted and/or generated source code is contained in the tarballs (cf., http://monetdb.cwi.nl/Download/).

Stefan

...

With kind regards,

Tristan Pothoven

Stefan Manegold wrote:

...

On Fri, Dec 07, 2007 at 10:29:07PM +0100, Djoerd Hiemstra wrote:

...

Here are some remarks from Tristan Pothoven here in Twente for installing the stable MonetDB/XQuery on FreeBSD (FreeBSD 6.2-RELEASE-p7). He did the following: 1. 'make' on FreeBSD cannot cope with the wildcards in some of the Makefiles. No problem if you use gmake instead. yes, we do require GNU make ('gmake') as documented in (a.o.) MonetDB/HowToStart.rst MonetDB4/HowToStart MonetDB5/HowToStart buildtools/README http://monetdb.cvs.sourceforge.net/*checkout*/monetdb/MonetDB4/HowToStart http://monetdb.cvs.sourceforge.net/*checkout*/monetdb/MonetDB5/HowToStart http://monetdb.cvs.sourceforge.net/*checkout*/monetdb/MonetDB/HowToStart.rst http://monetdb.cvs.sourceforge.net/*checkout*/monetdb/buildtools/README

...

2. Changes in sourcefiles: Package MonetDB: file: monet_utils.h original: #if HAVE_ALLOCA_H changed to: #ifdef HAVE_ALLOCA_H Package Pathfinder: file: pathfinder.h original: #if HAVE_ALLOCA_H changed to: #ifdef HAVE_ALLOCA_H Thanks! We'll look into this.

...

3. Furthermore, it seems that the files parser.tab.h and parser.tab.c, are not generated (are they generated?) correctly. Tristan took them from the tarball on the monetdb cwi site. Similarly, in the pftijah module with nexi.tab.c and nexi.tab.h. Hm, what does "not generated" mean --- which source did you (or Tristan) start with (CVS check out or tarball; which version) and hoe did you (or Tristan) compile them? As far as I'm aware, all files are either in the source or generated during the build process; if that's not the case, it's a bug --- but to locate and fix it we need some more specific info about what you starting point is/was and what you do/did to compile MonetDB --- "doesn't work" / "files are missing" does not help us very much ...

Stefan

...

Best, Djoerd.

-------- Original Message -------- Subject: * Re: [IR] Vraag met betrekking tot PFTijah / MonetDB Date: Fri, 23 Nov 2007 17:06:05 +0100 From: Tristan Pothoven To: Djoerd Hiemstra CC: Vliet,W.M.van(stud-INF)

Hallo Djoerd (en Marijn, de jongen van de grote xml),

Over de installatie van de stable release (zoals op de dbapps site, onder CVS) op FreeBSD (FreeBSD 6.2-RELEASE-p7) heb ik het volgende te melden:

Je moet per definitie gmake gebruiken ipv make. De make op FreeBSD kan niet overweg met de wildcards die in sommige Makefile's staan. Gmake kan dit wel.

Wijzigingen in de sourcefiles: Package MonetDB: file: monet_utils.h origineel: #if HAVE_ALLOCA_H vervanging: #ifdef HAVE_ALLOCA_H

Package Pathfinder: file: pathfinder.h origineel: #if HAVE_ALLOCA_H vervanging: #ifdef HAVE_ALLOCA_H

Verder heb ik geen wijzigingen in de code moeten aanbrengen.

Wel misten er nog wat files in de pathfinder module. Ergens in de parser (vergeef me dat ik de exacte locatie niet meer weet) missen de files parser.tab.h en parser.tab.c, deze heb ik gehaald uit de tarball beschikbaar op de monetdb cwi site.

In de pftijah module missen nexi.tab.c en nexi.tab.h. (Op dezelfde manier achterhaald en gekopieerd).

Ik geef toe, het was nachtwerk voor mij, dus mogelijke fouten die ik per ongeluk verzonnen heb: mijn excuses daarvoor, maar iig doet hij het nu. :)

Groeten,

Tristan

On Tue, Dec 11, 2007 at 02:18:52PM +0100, Fabian Groffen wrote:

On 07-12-2007 22:29:07 +0100, Djoerd Hiemstra wrote:

...

Here are some remarks from Tristan Pothoven here in Twente for installing the stable MonetDB/XQuery on FreeBSD (FreeBSD 6.2-RELEASE-p7). He did the following: 1. 'make' on FreeBSD cannot cope with the wildcards in some of the Makefiles. No problem if you use gmake instead.

The latest monetdb-install.sh script uses gmake when available (such as on FreeBSD and Solaris).

...

2. Changes in sourcefiles: Package MonetDB: file: monet_utils.h original: #if HAVE_ALLOCA_H changed to: #ifdef HAVE_ALLOCA_H Package Pathfinder: file: pathfinder.h original: #if HAVE_ALLOCA_H changed to: #ifdef HAVE_ALLOCA_H

Indeed, gcc on FreeBSD appears to choke on this. I fixed it in the current branch (sorry, my FreeBSD machine is too slow and I just did current initially).

If macro X is defined and equal to either 0 or 1, #if X is IMHO a valid C preprorocessor derective and should hence work fine. In fact, in such case the semantics of #if X is obviously not the same as that of #ifdef X (Admittedly, most in most if not all cases you changed, indeed `#ifdef X` was / should have been intended, not `#if X`.) What excatly did the gcc on FreeBSD complain about

There are occurences of #if @1 and #if CMD_@1 in the M4, M5 and XQuery sources. I suspect they will fail in the same way (i.e. the guard may do something else than expected), but I am not sure what the appropriate fix there is.

These case *might* indeed mean what they say: #if @1 #if CMD_@1 with @1 / CMD_@1 being either 0 or 1. Stefan

...

3. Furthermore, it seems that the files parser.tab.h and parser.tab.c, are not generated (are they generated?) correctly. Tristan took them from the tarball on the monetdb cwi site. Similarly, in the pftijah module with nexi.tab.c and nexi.tab.h.

This question already has been answered by Stefan.

-- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

On 11-12-2007 16:59:18 +0100, Stefan Manegold wrote:

...

...

original: #if HAVE_ALLOCA_H changed to: #ifdef HAVE_ALLOCA_H

Indeed, gcc on FreeBSD appears to choke on this. I fixed it in the current branch (sorry, my FreeBSD machine is too slow and I just did current initially).

If macro X is defined and equal to either 0 or 1,

#if X

is IMHO a valid C preprorocessor derective and should hence work fine. In fact, in such case the semantics of

#if X

is obviously not the same as that of

#ifdef X

(Admittedly, most in most if not all cases you changed, indeed `#ifdef X` was / should have been intended, not `#if X`.)

What excatly did the gcc on FreeBSD complain about

For my machine it was that alloca.h is not an existing include file. So the guard that should have prevented from including, did not work. This may very well not be a FreeBSD issue, as most other systems I know *DO* have alloca.h available, so it might very well just has gone unnoticed.

...

There are occurences of #if @1 and #if CMD_@1 in the M4, M5 and XQuery sources. I suspect they will fail in the same way (i.e. the guard may do something else than expected), but I am not sure what the appropriate fix there is.

These case *might* indeed mean what they say:

#if @1 #if CMD_@1

with @1 / CMD_@1 being either 0 or 1.

I guessed something like that. So those appear to be correct. I prefer proper comparisons in those cases anyway, but that's just beauty/readability.