pgsql-server/src backend/bootstrap/Tag: backen ...

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:

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.

Plus, the mirrors will all pull it down also, so gives ppl 'closer' access
in some cases :)

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