Обсуждение: pgsql-server/src backend/bootstrap/Tag: backen ...
pgsql-server/src backend/bootstrap/Tag: backen ...
От
momjian@svr1.postgresql.org (Bruce Momjian)
Дата:
CVSROOT: /cvsroot
Module name: pgsql-server
Changes by: momjian@svr1.postgresql.org 03/09/07 19:51:55
Added files:
src/backend/bootstrap: Tag: WIN32_DEV bootparse.c bootscanner.c
bootstrap_tokens.h
src/backend/parser: Tag: WIN32_DEV gram.c parse.h scan.c
src/interfaces/ecpg/preproc: Tag: WIN32_DEV pgc.c preproc.c
preproc.h
src/pl/plpgsql/src: Tag: WIN32_DEV pl.tab.h pl_gram.c pl_scan.c
Log message:
Add bison/lex created files.
momjian@svr1.postgresql.org (Bruce Momjian) writes:
> Added files:
> src/backend/bootstrap: Tag: WIN32_DEV bootparse.c bootscanner.c
> bootstrap_tokens.h
> src/backend/parser: Tag: WIN32_DEV gram.c parse.h scan.c
> src/interfaces/ecpg/preproc: Tag: WIN32_DEV pgc.c preproc.c
> preproc.h
> src/pl/plpgsql/src: Tag: WIN32_DEV pl.tab.h pl_gram.c pl_scan.c
> Log message:
> Add bison/lex created files.
I thought the consensus of the discussion was that this was not
necessary. It sure doesn't strike me as a good idea.
regards, tom lane
Tom Lane wrote: > momjian@svr1.postgresql.org (Bruce Momjian) writes: > > Added files: > > src/backend/bootstrap: Tag: WIN32_DEV bootparse.c bootscanner.c > > bootstrap_tokens.h > > src/backend/parser: Tag: WIN32_DEV gram.c parse.h scan.c > > src/interfaces/ecpg/preproc: Tag: WIN32_DEV pgc.c preproc.c > > preproc.h > > src/pl/plpgsql/src: Tag: WIN32_DEV pl.tab.h pl_gram.c pl_scan.c > > > Log message: > > Add bison/lex created files. > > I thought the consensus of the discussion was that this was not > necessary. It sure doesn't strike me as a good idea. This is only in the WIN32_DEV, where installing bison/flex is a pain. I copy the needed files over manually when I update that CVS from HEAD. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> I thought the consensus of the discussion was that this was not
>> necessary. It sure doesn't strike me as a good idea.
> This is only in the WIN32_DEV, where installing bison/flex is a pain. I
> copy the needed files over manually when I update that CVS from HEAD.
That's not a pain? You don't expect that WIN32_DEV will be broken on a
regular basis because its derived files are out of date?
Mind you, I do not actually give a darn whether WIN32_DEV is broken.
What bothers me about this is that if it's considered a good idea for
WIN32_DEV (whose only users, presumably, are developers clueful enough
to obtain the needed tools for themselves) then whenever Windows support
gets merged back to HEAD, we will be feeling pressure to do the same in
the HEAD branch. And that is something up with which I will not put.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> I thought the consensus of the discussion was that this was not > >> necessary. It sure doesn't strike me as a good idea. > > > This is only in the WIN32_DEV, where installing bison/flex is a pain. I > > copy the needed files over manually when I update that CVS from HEAD. > > That's not a pain? You don't expect that WIN32_DEV will be broken on a > regular basis because its derived files are out of date? > > Mind you, I do not actually give a darn whether WIN32_DEV is broken. > What bothers me about this is that if it's considered a good idea for > WIN32_DEV (whose only users, presumably, are developers clueful enough > to obtain the needed tools for themselves) then whenever Windows support > gets merged back to HEAD, we will be feeling pressure to do the same in > the HEAD branch. And that is something up with which I will not put. It is just easier for them to get start. Yea, they will need it when it is merged. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > Tom Lane wrote: > > >> I thought the consensus of the discussion was that this was not > > >> necessary. It sure doesn't strike me as a good idea. > > > > > This is only in the WIN32_DEV, where installing bison/flex is a pain. I > > > copy the needed files over manually when I update that CVS from HEAD. > > > > That's not a pain? You don't expect that WIN32_DEV will be broken on a > > regular basis because its derived files are out of date? > > > > Mind you, I do not actually give a darn whether WIN32_DEV is broken. > > What bothers me about this is that if it's considered a good idea for > > WIN32_DEV (whose only users, presumably, are developers clueful enough > > to obtain the needed tools for themselves) then whenever Windows support > > gets merged back to HEAD, we will be feeling pressure to do the same in > > the HEAD branch. And that is something up with which I will not put. > > It is just easier for them to get start. Yea, they will need it when it > is merged. Also, keep in mind that in the end most folks will be building under MinGW using a release tarball, that has those output files. We haven't gotten a MinGW release yet, so they have to build all the stuff. I use my unix bison/flex to build, but other's don't have that capability. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Tom Lane wrote:
>>> I thought the consensus of the discussion was that this was not
>>> necessary. It sure doesn't strike me as a good idea.
> Also, keep in mind that in the end most folks will be building under
> MinGW using a release tarball, that has those output files. We haven't
> gotten a MinGW release yet, so they have to build all the stuff.
Well, that's a fair argument, but why don't you get Marc to set up
nightly snapshots for the WIN32_DEV branch? That only costs cycles
in the short term. Polluting CVS with updates to derived files will
cost us CVS storage forever.
regards, tom lane
On Sun, 7 Sep 2003, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> Tom Lane wrote: > >>> I thought the consensus of the discussion was that this was not > >>> necessary. It sure doesn't strike me as a good idea. > > > Also, keep in mind that in the end most folks will be building under > > MinGW using a release tarball, that has those output files. We haven't > > gotten a MinGW release yet, so they have to build all the stuff. > > Well, that's a fair argument, but why don't you get Marc to set up > nightly snapshots for the WIN32_DEV branch? That only costs cycles > in the short term. Polluting CVS with updates to derived files will > cost us CVS storage forever. Easy enough, and done ... ftp://ftp.postgresql.org/pub/win32_dev will have it run nighty like the regular snapshot
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> Tom Lane wrote: > >>> I thought the consensus of the discussion was that this was not > >>> necessary. It sure doesn't strike me as a good idea. > > > Also, keep in mind that in the end most folks will be building under > > MinGW using a release tarball, that has those output files. We haven't > > gotten a MinGW release yet, so they have to build all the stuff. > > Well, that's a fair argument, but why don't you get Marc to set up > nightly snapshots for the WIN32_DEV branch? That only costs cycles > in the short term. Polluting CVS with updates to derived files will > cost us CVS storage forever. Hmm, another problem is that I don't think there is a flex port for MinGW --- at least I remember someone saying they found bison, but not flex, so if they grab the snapshot, they will not be able to use CVS to do development and diffs. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Marc G. Fournier wrote: > > > On Sun, 7 Sep 2003, Tom Lane wrote: > > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > >> Tom Lane wrote: > > >>> I thought the consensus of the discussion was that this was not > > >>> necessary. It sure doesn't strike me as a good idea. > > > > > Also, keep in mind that in the end most folks will be building under > > > MinGW using a release tarball, that has those output files. We haven't > > > gotten a MinGW release yet, so they have to build all the stuff. > > > > Well, that's a fair argument, but why don't you get Marc to set up > > nightly snapshots for the WIN32_DEV branch? That only costs cycles > > in the short term. Polluting CVS with updates to derived files will > > cost us CVS storage forever. > > Easy enough, and done ... > > ftp://ftp.postgresql.org/pub/win32_dev > > will have it run nighty like the regular snapshot Oh, that's nice. I put it on my web site so people don't need CVS installed. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Hmm, another problem is that I don't think there is a flex port for
> MinGW --- at least I remember someone saying they found bison, but not
> flex, so if they grab the snapshot, they will not be able to use CVS to
> do development and diffs.
So? Supplying the derived files via CVS rather than via snapshots
won't improve matters at all for people who haven't got the tools.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Hmm, another problem is that I don't think there is a flex port for > > MinGW --- at least I remember someone saying they found bison, but not > > flex, so if they grab the snapshot, they will not be able to use CVS to > > do development and diffs. > > So? Supplying the derived files via CVS rather than via snapshots > won't improve matters at all for people who haven't got the tools. Why do you need the tools if CVS has the files? I added something to configure so the derived files are newer than the others. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Sun, 7 Sep 2003, Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > >> Tom Lane wrote: > > >>> I thought the consensus of the discussion was that this was not > > >>> necessary. It sure doesn't strike me as a good idea. > > > > > Also, keep in mind that in the end most folks will be building under > > > MinGW using a release tarball, that has those output files. We haven't > > > gotten a MinGW release yet, so they have to build all the stuff. > > > > Well, that's a fair argument, but why don't you get Marc to set up > > nightly snapshots for the WIN32_DEV branch? That only costs cycles > > in the short term. Polluting CVS with updates to derived files will > > cost us CVS storage forever. > > Hmm, another problem is that I don't think there is a flex port for > MinGW --- at least I remember someone saying they found bison, but not > flex, so if they grab the snapshot, they will not be able to use CVS to > do development and diffs. Actually, if I recall that same thread, one person mentioned downloading a MinGW bison port, and then could build flex no problem using that ... Basically, I agree with Tom ... if we are going to go the extra steps to support Win32, at least the Win32 ppl can do is take the extra steps to build using the same 'restrictions' as the Unix ppl go through ...
Marc G. Fournier wrote: > > Hmm, another problem is that I don't think there is a flex port for > > MinGW --- at least I remember someone saying they found bison, but not > > flex, so if they grab the snapshot, they will not be able to use CVS to > > do development and diffs. > > Actually, if I recall that same thread, one person mentioned downloading a > MinGW bison port, and then could build flex no problem using that ... > > Basically, I agree with Tom ... if we are going to go the extra steps to > support Win32, at least the Win32 ppl can do is take the extra steps to > build using the same 'restrictions' as the Unix ppl go through ... Well, the files are in there now --- I might as well just leave them so they don't have to go through that. This MinGW environment is much more limited than a Unix environment --- no bison, flex, cvs, or perl. Once people are invested in the port, I think they will install those tools, but I like to make the getting-started easier. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Marc G. Fournier wrote: > > Hmm, another problem is that I don't think there is a flex port for > > MinGW --- at least I remember someone saying they found bison, but not > > flex, so if they grab the snapshot, they will not be able to use CVS to > > do development and diffs. > > Actually, if I recall that same thread, one person mentioned downloading a > MinGW bison port, and then could build flex no problem using that ... > > Basically, I agree with Tom ... if we are going to go the extra steps to > support Win32, at least the Win32 ppl can do is take the extra steps to > build using the same 'restrictions' as the Unix ppl go through ... Also, those files will not move into main CVS, and no one in Win32 is going to be playing with changing any of the source files used by bison/flex. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> So? Supplying the derived files via CVS rather than via snapshots
>> won't improve matters at all for people who haven't got the tools.
> Why do you need the tools if CVS has the files?
Why do you need the tools if the nightly snapshots have the files?
Same either way AFAICS.
My objection is basically that CVS is a hugely inefficient mechanism
for delivering derived files. The cost is about the same from a
downloader's point of view as snapshot tarballs --- but we pay for each
update *forever* in CVS storage. I do not mind having CVS permanently
record every feature addition or bug fix; that's potentially-useful
history. But there is zero historical content in derived files.
> I added something to configure so the derived files are newer than the
> others.
Doesn't that break the scenario you were just citing where a WIN32_DEV
user is trying to fix something in a .y or .l file?
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> So? Supplying the derived files via CVS rather than via snapshots > >> won't improve matters at all for people who haven't got the tools. > > > Why do you need the tools if CVS has the files? > > Why do you need the tools if the nightly snapshots have the files? > Same either way AFAICS. > > My objection is basically that CVS is a hugely inefficient mechanism > for delivering derived files. The cost is about the same from a > downloader's point of view as snapshot tarballs --- but we pay for each > update *forever* in CVS storage. I do not mind having CVS permanently > record every feature addition or bug fix; that's potentially-useful > history. But there is zero historical content in derived files. Oh, that's true. Maybe I should just push the snapshots because those are easier, and cvs isn't even in MinGW. I mount a Unix directory for builds, so I have CVS and all the other tools. Once nice thing about CVS is that you don't have to download the whole tarball each time --- good for code in development like MinGW. Also, one thing I am doing is pushing HEAD changes down in to the branch so I get the HEAD Win32 fixes that go in, and merging will be easier. Isn't that going to make overhead too? > > I added something to configure so the derived files are newer than the > > others. > > Doesn't that break the scenario you were just citing where a WIN32_DEV > user is trying to fix something in a .y or .l file? Sure. I don't anticipate any changes made there. All the stuff left is backend startup stuff. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
> >>> I thought the consensus of the discussion was that this was not > >>> necessary. It sure doesn't strike me as a good idea. > > > Also, keep in mind that in the end most folks will be building > > under MinGW using a release tarball, that has those output files. > > We haven't gotten a MinGW release yet, so they have to build all > > the stuff. > > Well, that's a fair argument, but why don't you get Marc to set up > nightly snapshots for the WIN32_DEV branch? That only costs cycles > in the short term. Polluting CVS with updates to derived files will > cost us CVS storage forever. Um, why not just have someone with local CVSROOT access just rm -f the ,v file when the WIN32_DEV branch ceases to be useful? In the meantime, have the flex/bison files in CVS. Few will notice or care in the meantime other than possibly CVSup administrators. Just a thought. -sc -- Sean Chittenden
Sean Chittenden <sean@chittenden.org> writes:
>> Well, that's a fair argument, but why don't you get Marc to set up
>> nightly snapshots for the WIN32_DEV branch? That only costs cycles
>> in the short term. Polluting CVS with updates to derived files will
>> cost us CVS storage forever.
> Um, why not just have someone with local CVSROOT access just rm -f the
> ,v file when the WIN32_DEV branch ceases to be useful?
If we do that, we will lose the change histories from back when those
files were kept in CVS (five or more years ago). Perhaps this is not
important, but I'm hesitant to do it.
regards, tom lane
Tom Lane wrote: > Sean Chittenden <sean@chittenden.org> writes: > >> Well, that's a fair argument, but why don't you get Marc to set up > >> nightly snapshots for the WIN32_DEV branch? That only costs cycles > >> in the short term. Polluting CVS with updates to derived files will > >> cost us CVS storage forever. > > > Um, why not just have someone with local CVSROOT access just rm -f the > > ,v file when the WIN32_DEV branch ceases to be useful? > > If we do that, we will lose the change histories from back when those > files were kept in CVS (five or more years ago). Perhaps this is not > important, but I'm hesitant to do it. Right. I assume branches are kept in the same file as HEAD. I have decided not to regularly update the derived files in WIN32_DEV --- I will just keep the files in their place, and have configure 'touch' them to make them more recent when configure is run --- we are just trying to get the backend to start at this point. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
> > >> Well, that's a fair argument, but why don't you get Marc to set > > >> up nightly snapshots for the WIN32_DEV branch? That only costs > > >> cycles in the short term. Polluting CVS with updates to > > >> derived files will cost us CVS storage forever. > > > > > Um, why not just have someone with local CVSROOT access just rm > > > -f the ,v file when the WIN32_DEV branch ceases to be useful? > > > > If we do that, we will lose the change histories from back when > > those files were kept in CVS (five or more years ago). Perhaps > > this is not important, but I'm hesitant to do it. That's right... those files used to be in CVS... > Right. I assume branches are kept in the same file as HEAD. Correct, CVS abuses the RCS format. > I have decided not to regularly update the derived files in > WIN32_DEV --- I will just keep the files in their place, and have > configure 'touch' them to make them more recent when configure is > run --- we are just trying to get the backend to start at this > point. *shrug* It's just an RCS file and easily editable by those who have write access. As I said, just a thought and is something that's pretty common for FreeBSD's CVS meisters to do and shouldn't be an option that this project rules out. -- Sean Chittenden
Bruce Momjian writes: > Also, those files will not move into main CVS, and no one in Win32 is > going to be playing with changing any of the source files used by > bison/flex. That is just false. Look at the CVS history of these files. -- Peter Eisentraut peter_e@gmx.net
Bruce Momjian writes: > Well, the files are in there now --- I might as well just leave them so > they don't have to go through that. This MinGW environment is much more > limited than a Unix environment --- no bison, flex, cvs, or perl. The whole MinGW thing is overhyped. Install Cygwin and specify gcc -mno-cygwin when you compile. That gets you the same compilation environment that MinGW provides, but you can use all the Unix tools. > Once people are invested in the port, I think they will install those > tools, but I like to make the getting-started easier. Yeah, but if there is supposedly no cvs available in that environment, what is the point of this exercise? They're going to have to download a pre-cooked tarball anyway. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Bruce Momjian writes: > > > Also, those files will not move into main CVS, and no one in Win32 is > > going to be playing with changing any of the source files used by > > bison/flex. > > That is just false. Look at the CVS history of these files. I meant I wasn't going to _resurect_ those files in CVS HEAD, only in WIN32_DEV. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Peter Eisentraut wrote: > Bruce Momjian writes: > > > Well, the files are in there now --- I might as well just leave them so > > they don't have to go through that. This MinGW environment is much more > > limited than a Unix environment --- no bison, flex, cvs, or perl. > > The whole MinGW thing is overhyped. Install Cygwin and specify gcc > -mno-cygwin when you compile. That gets you the same compilation > environment that MinGW provides, but you can use all the Unix tools. But we still need to do the work of getting this to work without compatiblity libraries. It is try Cygwin has a nice development environment too. > > Once people are invested in the port, I think they will install those > > tools, but I like to make the getting-started easier. > > Yeah, but if there is supposedly no cvs available in that environment, > what is the point of this exercise? They're going to have to download a > pre-cooked tarball anyway. True. They could CVS from somewhere else and copy it to Win32, but they would need flex/bison on Win32 for the compile. It just seemed two less things for people to do. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
> > Yeah, but if there is supposedly no cvs available in that environment, > > what is the point of this exercise? They're going to have to download a > > pre-cooked tarball anyway. > > True. They could CVS from somewhere else and copy it to Win32, but they > would need flex/bison on Win32 for the compile. It just seemed two less > things for people to do. Windows has some of the best CVS clients out of all operating systems I've tried. Tortoise CVS is consistently one of the simplest and most useful.
Вложения
Bruce Momjian writes: > Peter Eisentraut wrote: > > Bruce Momjian writes: > > > > > Also, those files will not move into main CVS, and no one in Win32 is > > > going to be playing with changing any of the source files used by > > > bison/flex. > > > > That is just false. Look at the CVS history of these files. > > I meant I wasn't going to _resurect_ those files in CVS HEAD, only in > WIN32_DEV. That is not the point. The point is: you claim that no Windows developers are going to want to change those files. The fact is: A glance at the CVS history shows that these files have already been changed several times because of Windows-related work. -- Peter Eisentraut peter_e@gmx.net
Bruce Momjian writes: > > The whole MinGW thing is overhyped. Install Cygwin and specify gcc > > -mno-cygwin when you compile. That gets you the same compilation > > environment that MinGW provides, but you can use all the Unix tools. > > But we still need to do the work of getting this to work without > compatiblity libraries. That's what I'm saying: -mno-cygwin turns off all the Cygwin compatiblity libraries and compiles it just like MinGW. It's the same code. > > Yeah, but if there is supposedly no cvs available in that environment, > > what is the point of this exercise? They're going to have to download a > > pre-cooked tarball anyway. > > True. They could CVS from somewhere else and copy it to Win32, but they > would need flex/bison on Win32 for the compile. It just seemed two less > things for people to do. If they get cvs from "somewhere", why can't they get flex and bison from the same place? -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Bruce Momjian writes: > > > > The whole MinGW thing is overhyped. Install Cygwin and specify gcc > > > -mno-cygwin when you compile. That gets you the same compilation > > > environment that MinGW provides, but you can use all the Unix tools. > > > > But we still need to do the work of getting this to work without > > compatiblity libraries. > > That's what I'm saying: -mno-cygwin turns off all the Cygwin compatiblity > libraries and compiles it just like MinGW. It's the same code. I am not using any MinGW features. The changes I am making are needed for a Visual C port or any native port. I am using MinGW because there is no confusion over libraries I _don't_ want to use, and over possible license issues. We can switch to Cygwin if we wish --- the Win32 code will be the same. I don't even have a compile test for MinGW being present or anything. > > > Yeah, but if there is supposedly no cvs available in that environment, > > > what is the point of this exercise? They're going to have to download a > > > pre-cooked tarball anyway. > > > > True. They could CVS from somewhere else and copy it to Win32, but they > > would need flex/bison on Win32 for the compile. It just seemed two less > > things for people to do. > > If they get cvs from "somewhere", why can't they get flex and bison from > the same place? I am not sure. I don't understand why people are wasting time worrying about a few files resurected in CVS to assist Win32. If you want me to set up my own CVS so people aren't bothered, maybe I should do that. It is a pain to be having to answer so many questions about something that is micro-managing a project like this. If you want a vote on whether those files should be added, fine, if not, I would rather not hear complaints. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Peter Eisentraut wrote: > Bruce Momjian writes: > > > Peter Eisentraut wrote: > > > Bruce Momjian writes: > > > > > > > Also, those files will not move into main CVS, and no one in Win32 is > > > > going to be playing with changing any of the source files used by > > > > bison/flex. > > > > > > That is just false. Look at the CVS history of these files. > > > > I meant I wasn't going to _resurect_ those files in CVS HEAD, only in > > WIN32_DEV. > > That is not the point. The point is: you claim that no Windows developers > are going to want to change those files. The fact is: A glance at the CVS > history shows that these files have already been changed several times > because of Windows-related work. Uh, I am lost now. The derived files have changes for Windows? Oh, I do remember changes for WIN32 reserved words that are used in our grammar, but those are all done now. Right now, we have a TODO list, and are focusing on that. If someone changes it for Win32, I will update the file. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I don't understand why people are wasting time worrying about a few
> files resurected in CVS to assist Win32.
Because this approach incurs a long-term cost (CVS storage) to buy a
short-term benefit (Windows developers might not need flex&bison).
The long-term cost is not trivial --- if you look at the CVS history
for the short interval that we kept these files in CVS, you will see
lots of five-thousand-line diffs corresponding to trivial changes in
the gram.y source. We abandoned that approach for very good reasons.
It was already pointed out that Windows users wouldn't get any benefit
at all unless they installed a CVS client. Surely if they can do that,
they can install flex&bison too.
We decided years ago that the minimum requirement to use our CVS sources
on Unix systems was the ability to run flex and bison locally (and we've
not had much patience with people running old versions of same, either).
I don't see the argument why people helping to develop a cutting-edge
Windows port should be expected to be less competent than every single
Unix CVS user. (Other than the fact that they're using Windows in the
first place of course ;-)))
regards, tom lane
Bruce Momjian schrieb:
> Marc G. Fournier wrote:
>
>>>Hmm, another problem is that I don't think there is a flex port for
>>>MinGW --- at least I remember someone saying they found bison, but not
>>>flex, so if they grab the snapshot, they will not be able to use CVS to
>>>do development and diffs.
>>
>>Actually, if I recall that same thread, one person mentioned downloading a
>>MinGW bison port, and then could build flex no problem using that ...
>>
>>Basically, I agree with Tom ... if we are going to go the extra steps to
>>support Win32, at least the Win32 ppl can do is take the extra steps to
>>build using the same 'restrictions' as the Unix ppl go through ...
>
>
> Well, the files are in there now --- I might as well just leave them so
> they don't have to go through that. This MinGW environment is much more
> limited than a Unix environment --- no bison, flex, cvs, or perl.
You should really consider using MSys (the development environment by
one of the MinGW developers). It offers bash,perl,cvs,ssh,libtool,auto*
and more in 3+9MB. I can't imagine porting anything from unix to Windows
without that environment. It should even offer bison+flex.
Christof
Christof Petig wrote:
> >>Basically, I agree with Tom ... if we are going to go the extra steps to
> >>support Win32, at least the Win32 ppl can do is take the extra steps to
> >>build using the same 'restrictions' as the Unix ppl go through ...
> >
> >
> > Well, the files are in there now --- I might as well just leave them so
> > they don't have to go through that. This MinGW environment is much more
> > limited than a Unix environment --- no bison, flex, cvs, or perl.
>
> You should really consider using MSys (the development environment by
> one of the MinGW developers). It offers bash,perl,cvs,ssh,libtool,auto*
> and more in 3+9MB. I can't imagine porting anything from unix to Windows
> without that environment. It should even offer bison+flex.
I have Msys installed, but I don't see perl or cvs. Here is my /bin:
awk* egrep* infokey.exe* od.exe* start*
basename.exe* env.exe* install-info.exe* patch.exe* tail.exe*
bunzip2* ex* install.exe* printf* tar.exe*
bzip2.exe* expr.exe* less.exe* ps.exe* tee.exe*
cat.exe* false.exe* libW11.dll* pwd* texindex.exe*
chmod.exe* fgrep* ln.exe* rm.exe* touch.exe*
cmd* find.exe* lnkcnv* rmdir.exe* tr.exe*
cmp.exe* fold.exe* ls.exe* rvi* true.exe*
comm.exe* ftp* m4.exe* rview* uname.exe*
cp.exe* gawk.exe* make.exe* rvim* uniq.exe*
cut.exe* grep.exe* makeinfo.exe* rxvt.exe* vi*
date.exe* gunzip* md5sum.exe* sed.exe* view*
diff.exe* gzip.exe* mkdir.exe* sh.exe* vim.exe*
diff3.exe* head.exe* mount.exe* sleep.exe* wc.exe*
dirname.exe* id.exe* msys-1.0.dll* sort.exe*
echo* info.exe* mv.exe* split.exe*
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I don't understand why people are wasting time worrying about a few > > files resurected in CVS to assist Win32. > > Because this approach incurs a long-term cost (CVS storage) to buy a > short-term benefit (Windows developers might not need flex&bison). > The long-term cost is not trivial --- if you look at the CVS history > for the short interval that we kept these files in CVS, you will see > lots of five-thousand-line diffs corresponding to trivial changes in > the gram.y source. We abandoned that approach for very good reasons. > > It was already pointed out that Windows users wouldn't get any benefit > at all unless they installed a CVS client. Surely if they can do that, > they can install flex&bison too. > > We decided years ago that the minimum requirement to use our CVS sources > on Unix systems was the ability to run flex and bison locally (and we've > not had much patience with people running old versions of same, either). > I don't see the argument why people helping to develop a cutting-edge > Windows port should be expected to be less competent than every single > Unix CVS user. (Other than the fact that they're using Windows in the > first place of course ;-))) I already said I am not updating the derived files unless we have to make a Win32 fix for it. The CVS branch is only going to be active until we start 7.5 development. Marc, maybe you better make me a separate CVS tree for Win32, rather than branch. There are too many people who's desire for perfect extends even to the CVS branches. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I don't understand why people are wasting time worrying about a few > > files resurected in CVS to assist Win32. > > Because this approach incurs a long-term cost (CVS storage) to buy a > short-term benefit (Windows developers might not need flex&bison). > The long-term cost is not trivial --- if you look at the CVS history > for the short interval that we kept these files in CVS, you will see > lots of five-thousand-line diffs corresponding to trivial changes in > the gram.y source. We abandoned that approach for very good reasons. > > It was already pointed out that Windows users wouldn't get any benefit > at all unless they installed a CVS client. Surely if they can do that, > they can install flex&bison too. > > We decided years ago that the minimum requirement to use our CVS sources > on Unix systems was the ability to run flex and bison locally (and we've > not had much patience with people running old versions of same, either). > I don't see the argument why people helping to develop a cutting-edge > Windows port should be expected to be less competent than every single > Unix CVS user. (Other than the fact that they're using Windows in the > first place of course ;-))) Also, I am told flex doesn't run on MinGW properly --- not sure why. Anyway, buy continuing complaints, you are asking for a vote, so I will start one now. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
[trimmed CC a bit, though committer is OT, it clearly is the only mailing list involved. Time for a pgsql-win32?] Bruce Momjian schrieb: > Christof Petig wrote: >>>Well, the files are in there now --- I might as well just leave them so >>>they don't have to go through that. This MinGW environment is much more >>>limited than a Unix environment --- no bison, flex, cvs, or perl. >> >>You should really consider using MSys (the development environment by >>one of the MinGW developers). It offers bash,perl,cvs,ssh,libtool,auto* >>and more in 3+9MB. I can't imagine porting anything from unix to Windows >>without that environment. It should even offer bison+flex. there is an extra package called msysDTK (developer toolkit) http://sourceforge.net/project/shownotes.php?release_id=158856 and msysDTK-1.0.0-alpha-1.tar.gz includes perl (since actual msysDTK is an opaque .exe it's difficult for me to tell whether perl is in it, I clearly have perl.exe in my msys/bin). bison and flex are available from the gnuwin32 effort: http://gnuwin32.sourceforge.net/packages.html Christof PS: Never install normal windows binaries in msys/bin. There are special command line properties (directory structure compatibility) associated with msys/bin.
Christof Petig schrieb: > bison and flex are available from the gnuwin32 effort: > http://gnuwin32.sourceforge.net/packages.html additional comments from an mingw developer: Earnie Boyd schrieb: > Darko Prenosil wrote: >> Bison binary downloaded from MinGW site was not working - and that one >> was not compiled by me. > > I've marked it on my round tuit list to look at. Configuring with > --prefix=/mingw and doing a make && make install will correct your problem.