Re: [HACKERS] Bison 2.1 on win32
Hi. I was operating in a tentative way by 2.3. Still, it is not sufficient. However, it moves. I will think that I am glad, if it can adjust with Magnus. http://winpg.jp/~saito/MinGW/bison-2.3_win32_src.tgz Regards, Hiroshi Saito - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> To: "Magnus Hagander" <[EMAIL PROTECTED]> Cc: "PGSQL Hackers" Sent: Sunday, March 18, 2007 2:06 AM Subject: Re: [HACKERS] Bison 2.1 on win32 Magnus Hagander <[EMAIL PROTECTED]> writes: Do you happen to have a 2.2 around so you can see what happens there? Or does someone else have that? So I know which version to test against... 2.2 and 2.3 seem to use _MSC_VER in the same way. I had occasion to test both last fall, and they generate only trivially different outputs from our grammar. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Bison 2.1 on win32
Magnus Hagander <[EMAIL PROTECTED]> writes: > Do you happen to have a 2.2 around so you can see what happens there? Or > does someone else have that? So I know which version to test against... 2.2 and 2.3 seem to use _MSC_VER in the same way. I had occasion to test both last fall, and they generate only trivially different outputs from our grammar. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Bison 2.1 on win32
Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> Actually, looking at the GNU ftp site, there isn't even a version 2.2 >> available. There is a 2.1a which should have the fix (based on file >> dates - they don't use branches or tags in their cvs repository). > > Huh? At > http://ftp.gnu.org/gnu/bison/ > I see 2.0, 2.1, 2.2, 2.3, and no 2.1a. Gah. I clicked the wrong link that was titled "test releases" ;-) I just found a second ftp link when the first one didn't work. Should've read more carefully. Ok. So it looks like 2.2 should be fine as well, as soon as they put out a new win32 ver... (FYI, the code seems to come from data/c.m4) /Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Bison 2.1 on win32
Magnus Hagander <[EMAIL PROTECTED]> writes: > Actually, looking at the GNU ftp site, there isn't even a version 2.2 > available. There is a 2.1a which should have the fix (based on file > dates - they don't use branches or tags in their cvs repository). Huh? At http://ftp.gnu.org/gnu/bison/ I see 2.0, 2.1, 2.2, 2.3, and no 2.1a. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Bison 2.1 on win32
Magnus Hagander wrote: > I just tried building with Bison 2.1 on msvc, and it broke. For one > thing, the .BAT file rejects 2.1 as broken instead of 2.0, which is > obviously incorrect :-) Actually, looking at the GNU ftp site, there isn't even a version 2.2 available. There is a 2.1a which should have the fix (based on file dates - they don't use branches or tags in their cvs repository). But I'll go ahead and just say it's fixed in 2.3, and patch accordingly. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Bison 2.1 on win32
Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> The attached patch seems to fix the build issue. Does it seem >> acceptable/the right thing to do? > > No, it seems pretty bletcherous. That's kind of what I thought :-) >> Another option would be to just reject both 2.0 and 2.1 as broken to >> build pg with, I guess... > > In bison 2.3 (which is shipping with Fedora Core 6), all the uses of > __STDC__ seem to also test _MSC_VER: > > #if (defined __STDC__ || defined __C99__FUNC__ \ > || defined __cplusplus || defined _MSC_VER) > > If this fixes the problem, then I'd vote for just stating you need > bison >= 2.3 (or 2.2?) to build on MSVC. It certainly looks like it would fix it. However, the gnuwin32 project doesn't have 2.3, not even 2.2. But let's add a check and say we need it, and then we can fix it again once they do release that version if it's broken still... Do you happen to have a 2.2 around so you can see what happens there? Or does someone else have that? So I know which version to test against... //Magnus ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Bison 2.1 on win32
Magnus Hagander <[EMAIL PROTECTED]> writes: > The attached patch seems to fix the build issue. Does it seem > acceptable/the right thing to do? No, it seems pretty bletcherous. > Another option would be to just reject both 2.0 and 2.1 as broken to > build pg with, I guess... In bison 2.3 (which is shipping with Fedora Core 6), all the uses of __STDC__ seem to also test _MSC_VER: #if (defined __STDC__ || defined __C99__FUNC__ \ || defined __cplusplus || defined _MSC_VER) If this fixes the problem, then I'd vote for just stating you need bison >= 2.3 (or 2.2?) to build on MSVC. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Bison 2.1 on win32
Magnus Hagander wrote: I just tried building with Bison 2.1 on msvc, and it broke. For one thing, the .BAT file rejects 2.1 as broken instead of 2.0, which is obviously incorrect :-) But the generated C file also does not compile causing the error on http://msdn2.microsoft.com/en-us/library/93az0868.aspx, because msvc doesn't define __STDC__, which causes Bison to generate code it can't compile. Defining __STDC__ globally breaks several other places, since it affects a lot of include files that aren't necessarily others. The attached patch seems to fix the build issue. Does it seem acceptable/the right thing to do? Another option would be to just reject both 2.0 and 2.1 as broken to build pg with, I guess... I rolled back to 1.875 to get MSVC builds working. In the longer term, though, falling behind upstream is probably not a good idea. Should this be reported to the bison people? For now I could live with either of your solutions. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly